- From: David Hull <dmh@tibco.com>
- Date: Wed, 15 Jun 2005 14:40:34 -0400
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: public-ws-async-tf@w3.org
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.
Does that make sense?
Or (re-reading) did you mean that wsdl:required would mean that
anonymous responses aren't allowed? 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>
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 18:40:43 UTC