Re: Proposal for Async Extensions

David Hull wrote:
> I left out wsdl:required here because I don't think it's really
> applicable.  Including a particular <wsaw:ResponseBinding> advertises
> that you can send (non-anonymous) responses through that binding.  If
> you want to say that you only support HTTP for  responses, you include
> only the one response binding element.  If you provide more than one
> response binding element, then you're saying you'll accept response
> endpoints using any of those bindings.  In other words, there's no sense
> in providing more than one response element and singling out one as
> wsdl:required, and if there's only one response binding, then
> wsdl:required would be redundant.
> 

In the case where wsdl:required="true" on a wsaw:ResponseBinding, it 
would not make sense to have more than one wsaw:ResponseBinding. In fact 
it would be an error to have two wsaw:ResponseBinding with 
wsdl:require='true' on both.

> Does that make sense?
> 
> Or (re-reading) did you mean that wsdl:required would mean that
> anonymous responses aren't allowed? 

Yes, that's what I meant.

> If so, I would prefer to use some
> other marker for that situation.  For example, what would this mean:
> 
> <wsaw:ResponseBinding
> wsdl:required="true">http://www.w3.org/2003/05/soap/bindings/HTTP/<wsaw:ResponseBinding>
> <wsaw:ResponseBinding
> wsdl:required="false">http://www.w3.org/@@@@/@@/soap/bindings/some-other-binding/<wsaw:ResponseBinding>
> 

In the above case, the one with wsdl:required='false' would never be 
used. When wsdl:required='true' on a wsaw:ResponseBinding element then 
it would not make sense to specific > 1 wsaw:ResponseBinding; it would 
be an error to specific > 1 wsaw:ResponseBinding with wsdl:required='true'.

In any case, I'm trying to figure out how this proposal addresses the 
requirement where through WSDL I want to convey that separate HTTP 
connection MUST be used for the response.

-Anish
--

> Anish Karmarkar wrote:
> 
> 
>>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 19:02:12 UTC