- From: David Hull <dmh@tibco.com>
- Date: Wed, 15 Jun 2005 15:18:41 -0400
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, public-ws-async-tf@w3.org
- Message-id: <42B07F11.40607@tibco.com>
Yalcinalp, Umit wrote:
>Let me understand this better:
>
>- wsaw:ResponseBinding is only applicable when wsaw:UsingAddressing is
>engaged, right?
>
>
Not necessarily. Anonymous response could be useful in other contexts.
>- There may be multiple ResponseBinding elements, each defining a
>different binding option.
>
>
Yes.
>- If this element is not present, we assume the actual binding is in
>effect for the responses.
>
>
If it's not present, then you're left with either anonymous responses,
if the UTB supports it, or nothing, in which case the operation had
better be one-way.
>- I would guess this proposal applies to only request-response. I could
>not understand why this element would apply to specifically in-only case
>per Section 3 of your document. Robust-in is another discussion.
>
>
It applies to all three. Where does it appear to say otherwise?
>- Does the ResponseBinding element provide the same kind of granularity
>that WSDL binding section would provide? This is a WSDL question. If so,
>how. If not, why not. Maybe you did not think about this, or I missed
>the subleties.
>
I'm not sure exactly what the question is, here. My concern is that,
for the binding of any particular operation, you can determine what
response channels are available.
>
>
>Thanks.
>
>--umit
>
>
>
>
>
>>-----Original Message-----
>>From: public-ws-async-tf-request@w3.org
>>[mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
>>Sent: Wednesday, Jun 15, 2005 11:41 AM
>>To: Anish Karmarkar
>>Cc: public-ws-async-tf@w3.org
>>Subject: Re: Proposal for Async Extensions
>>
>>
>>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/H
>>
>>
>TTP/<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</w
>>
>>
>sa: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/EchoStringReque
>>
>>
>st</wsa:Action>
>
>
>>>> <wsa:ReplyTo>
>>>>
>>>>
>>>>
>>>>
>>>>
>><wsa:Address>http://www.w3.org/@@@@/@@/addressing/anonymous</w
>>
>>
>sa: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/EchoStringRespo
>>
>>
>nse</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/EchoStringReque
>>
>>
>st</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</w
>>
>>
>sa: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/EchoStringRespo
>>
>>
>nse</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/EchoStringReque
>>
>>
>st</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/EchoStringRespo
>>
>>
>nse</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:18:59 UTC