Re: Action Item

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would note that in the reverse HTTP case, where a SOAP message not
related to the initial request message may be sent, and the initial
request is processed asynchronously, the SOAP envelope would contain an
actual SOAP message. Is it possible to include a "full" SOAP message in
a 202 response?

- - JohnK

ext Marc Hadley wrote:
> +1, I don't like the requirement to include an empty SOAP envelope in 
> the 202 reply and note that this is contrary to the WS-I recommendation.
> 
> Marc.
> 
> On Dec 5, 2005, at 3:11 PM, Anish Karmarkar wrote:
> 
>>
>> 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/>
>>
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDlMKBmNJiOOM57NMRAq2kAJwNbJ6rik9SuxsXxn36p6k7+PXcsACgz0H2
9jvp/iUoA/R5piLtCLQjNNM=
=E3MU
-----END PGP SIGNATURE-----

Received on Monday, 5 December 2005 22:43:43 UTC