W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2005

Re: Action Item

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 05 Dec 2005 12:11:17 -0800
Message-ID: <43949EE5.6020106@oracle.com>
To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
CC: public-ws-addressing@w3.org

One comment below.
-Anish
--

Yalcinalp, Umit wrote:

<snip/>

>  
> 
> *3.1.2 SOAP 1.1/HTTP Extension Semantics by using wsaw:UsingAddressing 
> element:*
> 
>  
> 
> The presence of the wsaw:UsingAddressing element in the binding or 
> endpoint (port) components of the endpoint description extends the 
> semantics of the SOAP 1.1/HTTP binding. In the case of the WSDL 
> SOAP/HTTP synchronous binding for request-response operations, the 
> presence of the wsaw:UsingAddressing element changes the requirement 
> that the response message be sent over the same HTTP channel over which 
> the request was received. Further, the presence of the wsaw:Anonymous 
> element may specify how anonymous addresses are treated specific to an 
> operation defined in a binding.  Therefore, the wsa:replyTo header in 
> the request MAY contain an address with a value different from the 
> anonymous URI when wsaw:UsingAddressing marker is used by extending the 
> semantics of SOAP1.1/HTTP binding.
> 
>  
> 
> Usage of wsaw:UsingAddressing element indicates that SOAP1.1/HTTP 
> binding is allowed to use a separate connection for sending response 
> messages, instead of using the same HTTP connection. This extension 
> allows SOAP 1.1/HTTP to be used asynchronously. Hence, the response 
> message MAY be sent over the same HTTP channel over which the request 
> was received or by opening a separate connection, depending on the 
> following conditions:
> 
> ·         When the value of the [reply endpoint] in the request message 
> contains the anonymous URI as its address, the response MUST be sent 
> over the same HTTP channel. 
> 
> ·         When the value of [reply endpoint] contains an address that is 
> different than the anonymous URI, this extension requires that
> 
> o       The receipt of the request message MUST be acknowledged with a 
> status message (202) by the receiver using the HTTP connection that 
> generated the request. The receipt message MUST contain an empty SOAP 
> envelope. / (Lets discuss this further)/
> 

Why is the empty SOAP Envelope required?

Does empty SOAP envelope mean: no SOAP headers and an empty body?

What seems strange about the empty SOAP envelope is that:
The MEP (or transmission primitive) says that the exchange is req-res 
and the requester gets back 2 soap messages (one "empty" envelope sent 
on the HTTP back channel and the other "real" reply on the ReplyTo EPR). 
Where is the empty envelope processed? Is it delivered to the App?

Thanks.

-Anish
--

> o       The actual response MUST be sent using a separate connection 
> using the address value of the response message specified by [reply 
> endpoint].
> 
>  
> 
> The wsaw:Anonymous element specifies the following semantics for a 
> specific operation in SOAP1.1/HTTP:
> 
>  
> 
> ·         “optional” value indicates the same semantics that is defined 
> for wsaw:UsingAddressing above, namely anonymous URIs are allowed, but 
> not required.
> 
> ·         “required” value indicates that the response message be sent 
> over the same HTTP channel over which the request was received. In 
> essence, it indicates requirement for always using synchronous responses.
> 
> ·         “prohibited” value indicates that SOAP1.1/HTTP binding must 
> always use a separate connection for sending response messages, instead 
> of using the same HTTP connection. In essence, it indicates requirement 
> for always using asynchronous responses.
> 
>  
> 
> /Note: We may consider including a paragraph here as a note to indicate 
> that SOAP processing rules dictate how responses/errors are generated 
> and sent to appropriate destinations depending on when the extensions 
> are processed and engaged following the discussion in the wg. **/
> 
> * *
> 

<snip/>
Received on Monday, 5 December 2005 20:11:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:10 GMT