Re: [sca-bindings] Use cases for HTTP binding

[Bryan Aupperle <aupperle@us.ibm.com>]

This is a good start to the discussion.
 Some additional thoughts/things to consider...

For accessing an HTTP-based service:
- This does not need not be limited
to XML-based results.  The result could be JSON or similar (can be
described with XSD+DFDL)
- Many services are going to be able
to return results in multiple formats.  The binding will need to indicate
one.
- There are several ways that request
parameters are transmitted, part of the URL, query parameters, in the body
of the request, etc.  we will need to either limit or allow for the
common patterns
- What is the "scope" of a
service (i.e. limit to just one shape of data or a set of related shapes)
 This may impact the nature of the URL specified in the binding as
well as the service interface

For providing an HTTP-based service:
- This should also include feeds and
modifiable data (e.g. a PUT adds or modifies/replaces the input object)
- Do we want to constrain the way request
parameters are transmitted?
- Same sort of "scope" questions
as for accessing an HTTP-based service

Overall question (not really related
to the binding but more so to HTTP-based services): Can we define one or
a small set of “generic interfaces” for basic HTTP-based service patterns?

As Anish pointed out, on a recent call
we need to be careful about labeling anything REST.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
WW Center of Excellence for Enterprise Systems & Banking Center of
Excellence Application Integration Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

From:	Jim Marino <jim.marino@gmail.com>
To:	OASIS Bindings <sca-bindings@lists.oasis-open.org>
Date:	08/09/2010 04:04 PM
Subject:	Re: [sca-bindings] Use cases for HTTP binding

---

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.
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.