EndpointRefs-47

I have written up a starting point for discussion of issue EPR-47.

 

In general, I do not believe that an EPR minter has a sufficient level
of technology available to provide stateful resources on the Web.  This
note does not cover whether stateful resource modeling is desireable or
not, which is the subject of a separate finding.   I have earlier
written up some thoughts on a soap transfer binding at [1] and [2], a
binding of WS-A Message Properties to HTTP at [3].

 

There are 3 key technical design decisions to integrating EPRs with the
Web via HTTP GET:

1) MAP Binding: How are WS-Addressing Message Addressing
Properties(MAPs), excluding Ref Params, bound to HTTP.   A trivial
approach is that each WSA MAP is serialized as an HTTP Header with
appropriate escaping.  One approach I mentioned is that a wsa:Action
that has a "*:get" value is bound to HTTP GET.  Or a wsa:Action that has
a "*:get*" value is bound to HTTP GET with the string after the get
added to the URI, as in [3].

 

2) RefParam Binding: How are EPR Reference Parameter(s) bound to an HTTP
GET.  One option is that Reference Parameter(s) are applied to the URI,
another option is they are serialized as HTTP Headers, and another is
they are serialized in http cookie header.

 

3) Binding description: How is the availability of the "WS-Addressing
GET" binding described in WSDL.

 

Each of these aspects will be affected by the richness of the set of
EPRs that are retrievable by GET.  For example, the binding of EPRs to
GET could say that the Ref Param QName is bound to the URI as just the
prefix:local name in the query, which is option 18 in [4].

 

In the complex matrix of choices, I tend to believe that the most
desirable solution is to make the simplest cases simple and possible.
There is the question of whether the complex cases, such as messages
with ReplyTo and FaultTo and complex Ref Params, should also be made
possible.  I proposed WS-Rest [5] to WS-RF last year, and wrote up [1].
There are 2 significant Web services specifications that use "generic"
verbs to retrieve resource state, that is WS-RF [6] and WS-Transfer.
One possible success criteria for any solution is whether either of
these specifications could be extended, say with a WSDL extension, that
would indicate availability the resources using HTTP GET.

 

Cheers,

Dave

 

[1]
http://www.pacificspirit.com/blog/2005/03/01/wsrest_continued_do_we_need
_an_http_transfer_soap_binding_and_simplified_wsdl

[2] http://www.w3.org/2001/tag/doc/ws-uri-05042002.html

[3]
http://www.pacificspirit.com/blog/2004/12/20/ruminations_on_wsaddressing
_and_transfer_protocols

[4] http://www.pacificspirit.com/blog/2004/04/29/binding_qnames_to_uris

[5] http://lists.oasis-open.org/archives/wsrf/200405/msg00018.html

[6] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf