Re: Proposal for Async Extensions

Question:

The example binding in the write-up is:

<binding name="operation name">
   <wsaw:UsingAddressing required=”true”/>
 
<wsaw:ResponseBinding>http://www.w3.org/2003/05/soap/bindings/HTTP/<wsaw:ResponseBinding>
   …
</binding>

i.e. wsdl:required="false" for the wsaw:ResponseBinding element.

What happens if wsdl:required="true" attribute is present on 
wsaw:ResponseBinding element? I assume that this means that a separate 
HTTP connection MUST be used for the response. Right?

-Anish
--

David Hull wrote:
> Attached please find a proposal for extensions for handling asynchronous 
> behavior.  This was an action item of mine from last Wednesday's call.
> 
> I believe the attached proposal has several advantages over previous 
> proposals, namely:
> 
>     * No new SOAP MEPs are needed to handle asynchronous messaging over
>       two-way transports.
>     * Given that messaging over a one-way transport simply means sending
>       a message, which any binding must be able to do, there may be no
>       need for a "one-way SOAP MEP" at all.
>     * Little if any change is needed to the existing HTTP SOAP binding.
>     * Acknowledgments may be explicitly correlated via [message id] and
>       may carry any other needed information.
>     * There are precise and complete rules for what combinations of
>       addressing headers are allowed in what circumstances.
>     * The [response binding] element covers the "Multiple Connection
>       HTTP" use case as a special case.
>     * Other bindings with backchannels are straightforward.
>     * It includes Tony's Timeline explicitly, addressing concerns about
>       when faults may or must be sent on the backchannel.  We may want
>       to tone down some of the statements made in this section, but this
>       can be done without disturbing the rest of the rules.
>     * It's short.  Most of the bulk is illustrative examples.  The
>       normative material runs to a page or two.
> 
> 
> ------------------------------------------------------------------------
> 
> Extensions for Asynchronous Message Exchange
> 
> 
>   1         SOAP Bindings
> 
> 
>     1.1      Anonymous Response feature
> 
> SOAP bindings MAY support the /anonymous response/ feature.  Such a 
> binding MUST provide a means of sending a reply directly to the sender 
> of a given message, independent of the contents of the SOAP message itself.
> 
> 
>       1.1.1      Response Correlation property
> 
> Bindings which support the anonymous response feature MAY provide a 
> means of correlating responses with the message to which they are 
> responding, independent of the contents of the SOAP message itself.  In 
> such a case, the value of the /response correlation/ property for that 
> binding is /true./  Otherwise it is /false/.
> 
> 
>     1.2      Marker message
> 
> An endpoint receiving a SOAP message (other than an anonymous response) 
> using a binding which supports the anonymous response feature MUST 
> produce a SOAP response to the sender, as per the SOAP request-response 
> MEP.  If the endpoint does not respond with a fault or an 
> application-level response, it MUST indicate that no further response 
> will be sent on the anonymous response channel, by sending a message 
> with an [action] property of 
> http://www.w3.org/@@@@/@@/addressing/marker. This message MAY also have 
> any other content, as appropriate.
> 
>  
> 
> Bindings MAY provide optimized means of transferring particular forms of 
> messages with this [action].
> 
> 
>   2         WSDL Extensions
> 
> 
>     2.1      Response Binding element
> 
> WSDL binding elements MAY include zero or more [response binding] child 
> elements.  The value of such an element MUST be an IRI denoting a SOAP 
> underlying transport binding.  This infoset item is represented as an 
> element with QName |wsaw:ResponseBinding|.
> 
> 
>     2.2      Using Addressing element
> 
> WSDL binding elements MAY include zero or one [using addressing] child 
> elements.  If this element is present, the operation MUST follow the 
> rules specified in the WS-Addressing Core, SOAP Binding and WSDL Binding 
> specifications.  This infoset item is represented as an element with 
> QName |wsaw:UsingAddressing|.
> 
> 
>   3         Interaction with WS-Addressing
> 
> The following uses the WSDL 2.0 names for MEPs, with the understanding 
> that the same considerations apply in the context of WSDL 1.1.  This 
> section applies only to the in-only, robust in-only and in-out MEPs.
> 
> 
>     3.1      Supported Response Bindings
> 
> For any given operation, the set of /supported response bindings/ 
> contains all, and exactly all, of the following IRIs:
> 
>     * The IRI |http://www.w3.org/@@@@/@@/addressing/anonymous|, if the
>       transport binding for the operation supports the anonymous
>       response feature.
>     * The values of all [response endpoint] children of the binding element
> 
> Unless the operation is in-only, this set MUST NOT be empty.
> 
> 
>     3.2      Compatibility of endpoints and supported response bindings
> 
> For a given /in /message in a WSDL MEP the set of /response endpoints/ is
> 
>     * The empty set in an in-only MEP
>     * The set {[fault endpoint]} in a robust in-only MEP.
>     * The set {[fault endpoint], [response endpoint]} in an in-out MEP.
> 
> All response endpoints for a message MUST be compatible with exactly one 
> of the supported response binding IRIs for the operation.  Note that 
> this is automatically true for an in-only operation.  An endpoint is 
> compatible with a binding IRI if
> 
>     * The [address] of the endpoint and the binding IRI are both
>       |http://www.w3.org/@@@@/@@/addressing/anonymous|
>     * The binding specified by the binding IRI provides a means of
>       sending a message to the [address] of the endpoint.
> 
> An endpoint receiving a message with incompatibly specified response 
> endpoints MUST attempt to fault if an anonymous response channel is 
> available, as per section 3.3 below.
> 
> 
>     3.3      Faults and the anonymous response channel
> 
> An endpoint supporting the anonymous response channel may encounter 
> errors at various stages in processing the message.
> 
>     * If such an error occurs before the [fault endpoint] property is
>       found to be valid, or the [fault endpoint] property is valid and
>       has the [address]
>       |http://www.w3.org/@@@@/@@/addressing/anonymous|, the endpoint
>       MUST attempt to send an appropriate fault on the anonymous
>       response channel.
>     * Otherwise (i.e., the [fault endpoint] is valid and is not directed
>       to the anonymous response channel)
>           o If the error occurs while the responding endpoint is in the
>             /receiving/ state (i.e., it has not yet begun to send a
>             response, and no failure has occurred), the endpoint MAY
>             attempt to send a fault on either the anonymous response
>             channel, or to the [fault endpoint], but MUST attempt to
>             send a fault.
>           o If the error occurs while the responding endpoint is in the
>             /sending, fail/ or /success/ state, the endpoint MUST
>             attempt to send a fault to the [fault endpoint].
> 
> 
>     3.4      Message ID
> 
> In addition to any requirements placed by the WS-Addressing 
> specifications, an /in/ message SHOULD contain a [message id] property 
> if the [address] of at least one response endpoint is not 
> |http://www.w3.org/@@@@/@@/addressing/anonymous|.
> 
> 
>   1         Existing bindings
> 
> Authors of new underlying transport bindings are encouraged to specify 
> whether the binding supports the anonymous response feature, and if so, 
> the value of the response correlation property and any optimizations for 
> marker messages.  The following supplements the existing SOAP/HTTP 
> binding by supplying this information for it.
> 
> 
>     1.1      SOAP/HTTP
> 
> The SOAP/HTTP binding supports the anonymous response feature with 
> response correlation /true./  The anonymous response channel is simply 
> the normal HTTP response mechanism.  An HTTP response with status code 
> 202 (Accepted) and no SOAP body is equivalent to a SOAP response with an 
> [action] property of |http://www.w3.org/@@@@/@@/addressing/marker|, no 
> other headers and no body.
> 
>  
> 
> The practical consequence of this is that a WSDL binding with 
> |transport="http://schemas.xmlsoap.org/soap/http" |and| a 
> <wsaw:UsingAddressing> |element present will follow the rules given in 
> sections 1-3 above, as illustrated in the non-normative examples in 
> section 5 below.
> 
>  
> 
> 
>   2         Non-normative examples
> 
> 
>     2.1      WSDL Fragments
> 
> These examples illustrate three operations: An in-only /Ping/ operation, 
> a robust in-only /RobustPing/ operation, and an in-out/ EchoString/ 
> operation.  They are defined abstractly by:
> 
>  
> 
> |<operation name="Ping">|
> 
> |   <input message="s0:PingMessageIn"/>|
> 
> |</operation>|
> 
> |…|
> 
> |<operation name="RobustPing">|
> 
> |   <input message="s0:RobustPingMessageIn"/>|
> 
> |</operation>|
> 
> |…|
> 
> |<operation name="EchoString"> |
> 
> |  <input message="s0:EchoStringMessageIn"/> |
> 
> |  <output message="s0:EchoStringMessageOut"/> |
> 
> |</operation>|
> 
> |…|
> 
>  
> 
> For the purposes of this illustration, they are bound by:
> 
>  
> 
> |<binding name="operation name"> |
> 
> |  <wsaw:UsingAddressing required=”true”/>|
> 
> |  <wsaw:ResponseBinding>http://www.w3.org/2003/05/soap/bindings/HTTP/<wsaw:ResponseBinding>|
> 
> |  …|
> 
> |</binding>|
> 
>  
> 
> This binding indicates that the rules specified by WS-Addressing are in 
> effect, and that responses may be sent via an HTTP connection separate 
> from the one carrying the request.
> 
> 
>     2.2      Sample HTTP wire traces
> 
> 
>       2.2.1      In-only
> 
> HTTP request:
> 
>  
> 
> POST /wsaService/service.ashx HTTP/1.1 
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/Ping</wsa:Action>
> 
>   </soap:Header>
> 
>   <soap:Body/>
> 
> </soap:Envelope>
> 
>  
> 
> HTTP response:
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
> 
>       2.2.2      Robust in-only with anonymous [fault endpoint]
> 
> HTTP request:
> 
>  
> 
> POST /wsaService/service.ashx HTTP/1.1 
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/RobustPing</wsa:Action>
> 
>     <wsa:FaultTo>
> 
>       <wsa:Address>http://www.w3.org/@@@@/@@/addressing/anonymous</wsa:Address>
> 
>     </wsa:FaultTo>
> 
>   </soap:Header>
> 
>   <soap:Body/>
> 
> </soap:Envelope>
> 
>  
> 
> HTTP response (if no fault occurred):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
>  
> 
> HTTP response (if a fault occurred):
> 
>  
> 
> HTTP/1.1 500 Internal Server Error
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
> 
>     …
> 
>   </soap:Header>
> 
>   <soap:Body>…</soap:Body>
> 
> <soap:Envelope>
> 
> 
>       2.2.3      Robust in-only with non-anonymous [fault endpoint]
> 
> HTTP request:
> 
>  
> 
> POST /wsaService/service.ashx HTTP/1.1 
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/RobustPing</wsa:Action>
> 
>     <wsa:FaultTo>
> 
>       <wsa:Address>http://www.example.org/fault</wsa:Address>
> 
>     </wsa:FaultTo>
> 
>     <wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
> 
>   </soap:Header>
> 
>   <soap:Body/>
> 
> </soap:Envelope>
> 
>  
> 
> HTTP response (in all cases):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
>  
> 
> Outgoing HTTP fault message (if a fault occurred):
> 
>  
> 
> POST fault HTTP/1.1
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
> 
>     <wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
> 
>     …
> 
>   </soap:Header>
> 
>   <soap:Body>…</soap:Body>
> 
> <soap:Envelope>
> 
>  
> 
> HTTP response to outgoing HTTP fault message (if a fault occurred):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
>  
> 
> 
>       2.2.4      In-out with anonymous [reply endpoint] and [fault endpoint]
> 
> HTTP request:
> 
>  
> 
> POST /wsaService/service.ashx HTTP/1.1 
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/EchoStringRequest</wsa:Action>
> 
>     <wsa:ReplyTo>
> 
>       <wsa:Address>http://www.w3.org/@@@@/@@/addressing/anonymous</wsa:Address>
> 
>     </wsa:ReplyTo>
> 
>     <wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
> 
>   </soap:Header>
> 
>   <soap:Body>EchoMe</soap:Body>
> 
> </soap:Envelope>
> 
>  
> 
> HTTP response (if no fault occurred):
> 
>  
> 
> HTTP/1.1 200 OK
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/EchoStringResponse</wsa:Action>
> 
>     <wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
> 
>   </soap:Header>
> 
>   <soap:Body>EchoMe</soap:Body>
> 
> <soap:Envelope>
> 
>  
> 
> HTTP response (if a fault occurred):
> 
>  
> 
> HTTP/1.1 500 Internal Server Error
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
> 
>     …
> 
>   </soap:Header>
> 
>   <soap:Body>…</soap:Body>
> 
> <soap:Envelope>
> 
>  
> 
> 
>       2.2.5      In-out with non-anonymous [reply endpoint] and
>       anonymous [fault endpoint]
> 
> HTTP request:
> 
>  
> 
> POST /wsaService/service.ashx HTTP/1.1 
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/EchoStringRequest</wsa:Action>
> 
>     <wsa:ReplyTo>
> 
>       <wsa:Address> http://www.example.org/reply</wsa:Address>
> 
>     </wsa:ReplyTo>
> 
>     <wsa:FaultTo>
> 
>       <wsa:Address>http://www.w3.org/@@@@/@@/addressing/anonymous</wsa:Address>
> 
>     </wsa:FaultTo>
> 
>     <wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
> 
>   </soap:Header>
> 
>   <soap:Body>EchoMe</soap:Body>
> 
> </soap:Envelope>
> 
>  
> 
> HTTP response (if no fault occurred):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
>  
> 
> Outgoing HTTP reply message (if no fault occurred):
> 
>  
> 
> POST /reply HTTP 1.1
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/EchoStringResponse</wsa:Action>
> 
>     <wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
> 
>   </soap:Header>
> 
>   <soap:Body>EchoMe</soap:Body>
> 
> <soap:Envelope>
> 
>  
> 
> HTTP response to outgoing reply message (if no fault occurred):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
>  
> 
> HTTP response to request message (if a fault occurred):
> 
>  
> 
> HTTP/1.1 500 Internal Server Error
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
> 
>     …
> 
>   </soap:Header>
> 
>   <soap:Body>…</soap:Body>
> 
> <soap:Envelope>
> 
>  
> 
> 
>       2.2.6      In-out with non-anonymous [reply endpoint] and [fault
>       endpoint]
> 
> HTTP request:
> 
>  
> 
> POST /wsaService/service.ashx HTTP/1.1 
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/EchoStringRequest</wsa:Action>
> 
>     <wsa:ReplyTo>
> 
>       <wsa:Address>http://www.example.org/reply</wsa:Address>
> 
>     </wsa:ReplyTo>
> 
>     <wsa:FaultTo>
> 
>       <wsa:Address> http://www.example.org/fault</wsa:Address>
> 
>     </wsa:FaultTo>
> 
>     <wsa:MessageId>uid:SomethingUnique</wsa:MessageId>
> 
>   </soap:Header>
> 
>   <soap:Body>EchoMe</soap:Body>
> 
> </soap:Envelope>
> 
>  
> 
> HTTP response to request message (in all cases):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
>  
> 
> Outgoing HTTP reply message (if no fault occurred):
> 
>  
> 
> POST /reply HTTP/1.1
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/EchoStringResponse</wsa:Action>
> 
>     <wsa:RelatesTo>uid:SomethingUnique</wsa:RelatesTo>
> 
>   </soap:Header>
> 
>   <soap:Body>EchoMe</soap:Body>
> 
> <soap:Envelope>
> 
>  
> 
> HTTP response to outgoing reply message (if no fault occurred):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
>  
> 
> Outgoing HTTP fault message (if a fault occurred):
> 
>  
> 
> POST /fault HTTP/1.1
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://www.w3.org/@@@@/@@/addressing/fault</wsa:Action>
> 
>     …
> 
>   </soap:Header>
> 
>   <soap:Body>…</soap:Body>
> 
> <soap:Envelope>
> 
>  
> 
> HTTP response to outgoing fault message (if a fault occurred):
> 
>  
> 
> HTTP/1.1 202 Accepted
> 
> 
>       2.2.7      In-only, headers needed in marker message
> 
> For various reasons, a SOAP marker message response may need to contain 
> SOAP headers beyond the <wsa:Action> header.  In this case, the response 
> should be a non-optimized SOAP message, as shown here:
> 
>  
> 
> HTTP request:
> 
>  
> 
> POST /wsaService/service.ashx HTTP/1.1 
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://tempuri.org/ServicePortType/Ping</wsa:Action>
> 
>   </soap:Header>
> 
>   <soap:Body/>
> 
> </soap:Envelope>
> 
>  
> 
> HTTP response:
> 
>  
> 
> HTTP/1.1 200 OK
> 
> <soap:Envelope>
> 
>   <soap:Header>
> 
>     <wsa:Action>http://www.w3.org/@@@@/@@/addressing/marker</wsa:action>
> 
>     <myns:SomeHeader>…</myns:SomeHeader>
> 
>   </soap:Header>
> 
>   <soap:Body/>
> 
> </soap:Envelope>
> 
>  
> 

Received on Wednesday, 15 June 2005 18:21:20 UTC