RE: Proposal for Async Extensions

Let me understand this better: 

- wsaw:ResponseBinding  is only applicable when wsaw:UsingAddressing is
engaged, right? 
- There may be multiple ResponseBinding elements, each defining a
different binding option. 
- If this element is not present, we assume the actual binding is in
effect for the responses. 
- 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. 
- 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. 

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:06:18 UTC