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

Jonathan Marsh wrote:
>
> 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.
>
I think these issues are also related with CR127.
+1 for improving the primer and promoting a simple HTTP dispatch mechanism.
This does not prevent anybody to use another mechanism.
>
> 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.
>
FWIW, our current implementation uses a try/catch approach:
Let's say that the base uri allows identifying the service.
We first do a verb dispatching step (GET/DELETE), then for each WSDL 
operation that uses the given verb, we try to apply the template.
The first template that matches the URI is selected.
The bad point is that in some cases, the matching order may change the 
selection result.
Anyway, your proposal is simpler and compatible with our current approach.
We might want to add that what should really be unique is the pair (HTTP 
Verb,URL) ?


> 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.
>
Please note that for a typical use of the HTTP binding with POST and XML 
content, the unique GED mechanism will still be usable.

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

Concerning HTTP interfaceless binding, I went to the conclusion that 
interfaces with two operations (one marked as safe and the other one not 
marked as safe) could always be safely bound to a HTTP interfaceless 
binding. This is a minimal functionality, but quite inline with REST for 
which the HTTP verb matters a lot.

Youenn
>
> [1] 
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html#adv-message-dispatch 
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-primer.html#adv-message-dispatch>
>
> **Jonathan Marsh** - http://www.wso2.com - 
> http://auburnmarshes.spaces.live.com
>

Received on Thursday, 4 January 2007 09:29:35 UTC