Another proposal for asynchronous support in SOAP and WSDL

On yesterday's async-tf wrap up call several of the participants  
agreed to send a summary of their current thinking to the WG, here is  
mine.

This proposal is mostly extracted from a proposal I sent to the async- 
tf in June[6] with some additions and corrections to address comments  
I received in the subsequent email thread.

The 'management summary' is that:

(1) The SOAP 1.2 HTTP binding gets modified to allow an empty HTTP  
response and support sending responses elsewhere using a subsequent  
HTTP request
(2) We extend the wsaw:UsingAddressing element to allow specification  
of the protocol 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: Either there is no response message or the  
response message 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

Note that from the perspective of the SOAP requestor, the binding  
state machine completes at this point, the next section describes  
what happens at the SOAP responder.

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 there is no response or 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 the latter 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."

Note that in the case of an async response, the SOAP responder  
switches roles to become a SOAP requestor using a new instance of the  
binding state machine.

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
[6] http://www.w3.org/mid/F37A5A89-14D6-4A46-96EC-E2581E7D43F6@Sun.COM


---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.