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)
- 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.
- 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>