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.

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.