RE: Another proposal for async extensions

 

> -----Original Message-----
> From: public-ws-async-tf-request@w3.org 
> [mailto:public-ws-async-tf-request@w3.org] On Behalf Of Marc Hadley
> Sent: Thursday, Jun 16, 2005 10:48 AM
> To: public-ws-async-tf@w3.org
> Subject: Another proposal for async extensions
> 
> Following yesterdays telcon I thought I should take the time 
> to write  
> up my thoughts on where we should be headed. This proposal adds some  
> deltas to the SOAP 1.2 HTTP binding to allow responses to go  
> elsewhere and to allow empty HTTP response entity bodies (we might  
> still want to define a one-way MEP but I don't think this is 
> strictly  
> necessary). This proposal also extends the wsaw:UsingAddressing WSDL  
> extension to allow specification of the bindings an endpoint 
> supports  
> for [reply endpoint] and [fault endpoint] messages addressing  
> properties.
> 
> Another proposal for Asynchronous Support in SOAP and WSDL
> 
> 1. SOAP 1.2 HTTP Binding
> 
> Tweak the existing SOAP 1.2 binding[1] as follows.
> 
> 1.1 New Features
> 
> Say that it supports the SOAP 1.2 Addressing 1.0 feature[2] 
> using the  
> SOAP 1.2 Addressing 1.0 Module[3].
> 
> 1.2 Update table 17[4]
> 
> Add a new row for HTTP response code 202
> 
> Status Code: 202
> reason phrase: Accepted
> Significance/Action: The response message (if any) will be sent to  
> the node identified by the http://www.w3.org/@@@@/@@/addressing/ 
> feature/ReplyEndpoint property of the SOAP 1.2 Addressing 1.0 feature 
> [2].
> NextState: Success
> 
> 1.3 Update table 19[5]
> 
> Update row describing status line to support HTTP response code 202:
> 
> Change: "200, or set according to Table 20 if a SOAP fault was  
> generated."
> To: "200, 202 or set according to Table 20 if a SOAP fault was  
> generated. 202 is used when the http://www.w3.org/@@@@/@@/addressing/ 
> feature/ReplyEndpoint property of the SOAP 1.2 Addressing 1.0 
> feature  
> requires a response to be sent to an alternate destination. In this  
> case the responding node follows the behaviour described in 7.5.1  
> Behavior of Requesting SOAP Node to send the response message to the  
> specified destination."
> 
> Update row describing HTTP entity body:
> 
> Change: "SOAP message serialized according to the rules for carrying  
> SOAP messages in the media type given by the Content-Type 
> header field."
> To: "Empty or SOAP message serialized according to the rules for  
> carrying SOAP messages in the media type given by the Content-Type  
> header field."
> 
> 2. WSDL (partly extracted and modified from David Hull's proposal)
> 
> 2.1 Extend the existing wsaw:UsingAddressing Element
> 
> Add an attribute 'asyncOnly' with a default value of 'false'. When  
> 'true' the endpoint only supports async interactions.
> 

How about supporting async, noAsync, or both? 

We would like an endpoint to support all three cases. Would you consider
that? This is in essence the guts of our original proposal... 


> Add a wsaw:ResponseBinding child element with cardinality  
> [0..unbounded]. The value of each of these is a binding  
> identification URI that specifies that the given endpoint can 
> support  
> [reply endpoint] and [fault endpoint] destinations using the  
> appropriate binding. If wsaw:UsingAddressing/@asyncOnly='true' then  
> there must be at least one wsaw:UsingAddressing/wsaw:ResponseBinding  
> element.
> 
> If there are zero wsaw:UsingAddressing/wsaw:ResponseBinding elements  
> then the only [destination] supported for [reply endpoint] 
> and [fault  
> endpoint] is the anonymous URI.
> 
> [1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapinhttp
> [2] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- 
> soap.html?content-type=text/html;%20charset=utf-8#s12feature
> [3] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- 
> soap.html?content-type=text/html;%20charset=utf-8#s12module
> [4] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ 
> #tabreqstatereqtrans
> [5] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/ 
> #tabresstaterecheads
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
> 
> 
>

Received on Thursday, 16 June 2005 19:07:25 UTC