- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Thu, 15 Sep 2005 10:31:58 -0400
- To: public-ws-addressing@w3.org
- Message-id: <1EFFF9BA-6069-4EFC-AEE3-EB4AD09770B2@Sun.COM>
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.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 15 September 2005 14:31:44 UTC