On Aug 4, 2010, at 2:06 AM, Eric Johnson wrote:
I agreed to an action item to write up, with respect to the
potential HTTP binding, the two use-cases I discussed in the
conference call. So here goes.
Description
|
Exploit an existing HTTP-based service that
has XML-based result. More specifically, a JAX-WS or
Ruby-On-Rails service, wherein the URLs for the service are
reasonably predictable. Map that to a set of operations
mapped to messages being exchanged
|
Preconditions
|
- "Parameters" to request data are simple strings
- Every "read" request needed can be mapped to an HTTP
GET
- WSDL portType is described with a small flat set of
parameters on input and a single XML element upon return
- Certain HTTP status codes can be mapped to application
level faults
- Authentication/authorization credentials are supplied
at deployment, and/or TLS with bi-directional
certification validation might be required.
|
What happens:
|
In binding the portType to an HTTP GET
request, the child elements of the request operation get
mapped to parameters on the URL. Default mapping is element
local name to parameter name. Binding needs to specify a
URL with substitution points.
Root element of response document is the response element
for the result.
In case of an HTTP error code, where specified, a fault is
mimicked for "replies."
|
Post-conditions
|
Invocations of the "reference" operation
return the XML results mapped to the language mapping of
said data structure
|
Description:
|
Stateful "monitor" of an service providing 1
or more atom feeds, supporting three operations
"getNewEntriesForFeedFoo", "getLastNEntriesForFeedFoo",
"getContentForFoo" - per Atom feed.
|
Preconditions:
|
Service that offers up one or more atom feeds
Atom feeds are changing slowly enough that polling for data
at lazy intervals (1 - 60 minutes) is sufficient
Customer has a name for each URL. Operations in the
interface follow a known pattern like
getNewEntriesForFeedFoo
Customer has particular data that they're interested in from
each feed, such as author, modification date, ID, other
metadata
|
What happens
|
A service requests an update from a specific
specific feed by calling getNewEntriesForFeedFoo (where
"Foo" changes per feed)
|
Post-conditions
|
Returns a list of new entries, the list of
the last N entries requested, or the content for the
particular entry.
|
Note, for this last case, it would be much more natural to define
the interface with "interface.atom", wherein the relevant metadata
would be flagged for each feed, and the content of the root element
of a feed entry was established. This would follow known mapping
rules to map to a WSDL expression of the same, if that was
required. Then again, I filed an issue for letting Assembly allow
non-WSDL interface descriptions for a reason....
On the service side, the one use-case I can think of is URL
addressability of read-only service information. This is
essentially the reverse of the first use-case described above, with
one additional caveat. It may be desirable to map to multiple URLs
(.xml, .rdf, .xhtml, .txt), so for the service side of this binding
a natural thing, I think would be to specify an XSLT file correlated
with a particular MIME type. In the XML case, that might be added
as a XSL processing instruction.
None of these use-cases gets at all close to REST, but they seem
like the might be useful in the abstract. I've not got specific
customer needs that are driving these ideas.
-Eric.
Has it been brought up to do a "REST" binding instead where operations are mapped to HTTP verbs and content is mapped to the content-type header instead? For Java implementation types, JAX-RS annotations could be used in a way similar to the way JAX-WS annotations are for WS-* protocols. Such an approach may prove to be more interoperable with other frameworks such as Ruby On Rails or .NET (which has something analogous to JAX-RS). I put REST in quotes since HATEOAS would likely not be accommodated in such a binding.
Jim
P.S. +1 on allowing non-WSDL interface descriptions. |