W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2006

Re: SOAP 1.1 One-way HTTP Binding doc

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Wed, 01 Feb 2006 09:42:58 -0500
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: paul.downey@bt.com, chrisfer@us.ibm.com, distobj@acm.org, dmh@tibco.com, dorchard@bea.com, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-id: <D98592DF-4725-4A25-8BE2-95C4612BD0E9@Sun.COM>
On Feb 1, 2006, at 1:18 AM, Anish Karmarkar wrote:
>
>>> However, given what Mark observed, I suspect
>>> that we might do well to specify that at a minimum, the SOAP  
>>> processing w/r/t SOAP headers MUST be performed before any  
>>> response is generated, so as to ensure that if a mU fault is  
>>> generated, it can be transmitted on the HTTP response (with a 500).
>> Except I might legitimately send back a 202 Accepted following  
>> securing the message in a database or putting it onto a reliable  
>> message queue, well before any SOAP processing has taken place.
>
> +1
>
That's one alternative.

> Or In the WSRX case, I might send back a 202 with a WSRX ack after  
> processing all the WSRX headers and storing the messages in a DB,  
> but before processing other non-WSRX headers.
>
That idea trouble me a bit, the SOAP processing model is all or  
nothing, allowing some headers to be processed and others to be  
ignored (at least for mU processing) diverges from the spec as I read  
it.

Marc.

>
>> For my money the ability to send a RX ACK in a 202 is interesting
>> and falls well within RFC2616's 202, but presumably would require  
>> SOAP processing generating MU faults etc, so would require more RX  
>> specific instruction in such a note building upon Dave's one-way  
>> note.
>> Paul
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.




Received on Wednesday, 1 February 2006 14:43:14 GMT

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