FW: Operation dispatch when there isn't a SOAP body.

FTR, dispositions below.  I accept them.

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com

 

  _____  

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Jonathan Marsh
Sent: Tuesday, January 02, 2007 11:37 AM
To: www-ws-desc@w3.org
Subject: Operation dispatch when there isn't a SOAP body.

 

Axis2 has encountered some issues with operation dispatch using the HTTP
binding.

 

For SOAP messages, Axis2 supports a variety of operation dispatch
mechanisms, including out-of-the-box support for wsa:Action, soap action,
and unique body QNames.  Both wsa:Action and unique body QNames are noted as
mechanisms enabling easy operation dispatch in the WSDL 2.0 primer [1].
Unique QNames and soap actions are used for tests in our test suite, to
eliminate the need for operation dispatch extensions (such as wsa:Action).

 

However, when the HTTP binding is in use, the SOAP-specific mechanisms
generally aren't sufficient.  There is no wsa:Action header or soap action
parameter.  When using GET, there is no body and thus no unique body QName
appearing in the message.  The same is true in the SOAP binding when using
the soap-response MEP.  The primer doesn't give any advice on what to do
here.

 

For an HTTP service, the obvious choice of mechanism for message dispatch
would be the URL of the service - defining a unique combination of the
{address} and the {http location} for each operation.  It would be desirable
to document something along this line in the primer.

 

There is a twist though - {http location} templating means there isn't a
fixed set of URLs to dispatch on - the URL is dependent upon the instance
data, and there is always the possibility that different data inserted into
different templates results in the same URL.  In general dealing with
templating in operation dispatch is somewhat complex.

 

To support various styles of URI generation, yet avoid the complexities of
messing with templates, I propose an operation dispatch mechanism that
considers the {address} and the part of the {http location} property
preceding the first unescaped "{" as a unique dispatching string.  This
supports the following scenarios:

1)      absolute {http location} values

2)      {http location} values that begin with the operation name

3)      {http location} values that are unique per operation (but don't
quote the operation name verbatim)

4)      {http location} values that begin with a fixed set of path segments
or query parameters unique to the operation.

 

While this mechanism it something Axis2 could implement independent of the
specification, it seems to me worthwhile to document the mechanism in the
Primer.

 

Proposed text:to append to [1].

 

When using the HTTP Binding, or when using the SOAP Binding with the
soap-response MEP, there is no SOAP envelope in a request message, and thus
mechanisms other than unique qualified names of global element declarations,
or headers such as wsa:Action, must be considered.  In these cases, the
{address} and {http location} properties may be constructed so as to provide
a location that can be correlated uniquely with an operation.  For instance,
one could prefix the {http location} property with the operation name, or
one could ensure that the portion of the {http location} preceding the first
unescaped "{" character be unique per operation.

 

 

This proposal was tracked as CR134 [2] and accepted.  The primer has been
updated [3].

 

[2] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR134

[3]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html#a
dv-message-dispatch

 

 

Furthermore, when a unique {http location} property is required for
operation dispatch, one must specify this per-operation detail, which
conflicts with the desire to define generic (interfaceless) HTTP bindings.
A potential solution would be to add another feature enabling unique
per-operation effective {http binding} values without specifying them at the
level of individual operations.  Here is a facility that might help:

 

Add a new whttp:locationDefault attribute to the binding element, which
would populate (conceptually) the {http location} property of each binding
operation without an {http location} specified.  In addition, a new token,
#operation, is introduced which is essentially a variable expanding to the
local part of the operation name.  Thus:

  <binding type=".../http" whttp:locationDefault="{#operation}?p={p1}"/>

Would be equivalent to:

 

  <binding type=".../http">

    <operation ref="firstOperation"

                  whttp:location="firstOperation?p={p1}"/>

     <operation ref="secondOperation"

                  whttp:location="secondOperation?p={p1}"/>

   </binding>

 

[1]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html#a
dv-message-dispatch

 

 

This proposal was tracked as CR135 [4] but declined due to schedule
constraints.

 

[4] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR135

 

 

Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
<http://auburnmarshes.spaces.live.com> http://auburnmarshes.spaces.live.com