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

Jonathan,

I am OK with improvements to the Primer.

The issue of dispatch is somewhat artificial. It was caused by the 
non-RESTful practice of using a single endpoint for all Web service 
requests and then relying on the SOAP engine to dispatch the request to 
the right implementation object. For example, the early Apache SOAP 
implementation called this endpoint the "router".

REST is based on the proper use of well-designed URLs. Web servers, 
including Java servlet containers, have the ability to map URLs to code, 
e.g. a servlet can handle a URL pattern.

Your proposal for the definition of a default HTTP location for 
interfaceless bindings is interesting. However, I wonder how useful an 
interfaceless binding is for REST. I think toolkits would probably 
implement some strategy for generating HTTP locations based on the input 
arguments of methods.

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca



"Jonathan Marsh" <jonathan@wso2.com> 
01/02/2007 04:09 PM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
<www-ws-desc@w3.org>, <www-ws-desc-request@w3.org>
Subject
RE: Operation dispatch when there isn't a SOAP body.






While deploying a set of services over HTTP and subsequently describing 
them with WSDL will naturally produce some way of correlating operations 
and messages, one has to take some care when working WSDL-first not to 
make it impossible or difficult to correlate operations and messages.  The 
operation dispatch section of the primer reminds authors of this.
 
With this issue I?m simply noting that when reading this section, and then 
trying to write services that bind to an HTTP GET, one will find the 
advice incomplete, as the methods described therein simply aren?t 
applicable unless there is a SOAP body.  If there were some advice I could 
have followed, maybe I wouldn?t have created the unusable testcases that I 
did.
 
Whether you find the Primer to be helpful in this regard is somewhat 
orthogonal to whether you find the Primer to be adequately complete ? my 
proposal simply intends to increase the completeness of the primer in this 
area.  Perhaps you?d be happier simply adding ?binding to HTTP GET or 
other transports that have no SOAP or XML payload? to the bullet list of 
things that make dispatch difficult.
 
Secondly, I had not realized before that interface-less bindings are 
incompatible out of the box with REST-style services (e.g. HTTP or SOAP 
using GET).  While it might be to late to do anything about it, it is at 
least an inadequacy in our interface-less binding support interesting 
enough to bring to the attention of the WG.
 
Jonathan Marsh - http://www.wso2.com - 
http://auburnmarshes.spaces.live.com
 

From: Arthur Ryman [mailto:ryman@ca.ibm.com] 
Sent: Tuesday, January 02, 2007 12:06 PM
To: Jonathan Marsh
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: Operation dispatch when there isn't a SOAP body.
 

Jonathan, 

Isn't dispatch implementation dependent? A URL is a URL. Web servers know 
how to deal with them. 

The issue here is really what a toolkit would do to generate a service 
skeleton. I think this belongs in specs like JAX-WS. 

Arthur Ryman,
IBM Software Group, Rational Division

blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca 


"Jonathan Marsh" <jonathan@wso2.com> 
Sent by: www-ws-desc-request@w3.org 
01/02/2007 02:36 PM 


To
<www-ws-desc@w3.org> 
cc
 
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. 
  
  
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#adv-message-dispatch 

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