- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Wed, 15 Jun 2005 15:26:40 -0400
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: David Hull <dmh@tibco.com>, public-ws-async-tf@w3.org
- Message-id: <28139DE9-658E-46D1-A00C-D39CC4FF743F@Sun.COM>
On Jun 15, 2005, at 3:01 PM, Anish Karmarkar wrote:
>
> 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.
>
That sounds a little odd since anon replies can still come back
before [reply endpoint] takes effect (mU faults e.g.) ...
Even if we get round that problem it seems odd to only be able to
demand use of one particular transport rather than just being able to
say "must be async".
Marc.
>
>> 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>
>>>>
>>>>
>>>>
>>>
>>>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Wednesday, 15 June 2005 19:27:04 UTC