- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 15 Jun 2005 11:21:02 -0700
- To: David Hull <dmh@tibco.com>
- CC: public-ws-async-tf@w3.org
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