Re: SOAP 1.1 One-way HTTP Binding doc

Please see my comments inlined below.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 02/02/2006 09:55:52 AM:

> 
> Response at the bootom.
> 
> Anish Karmarkar wrote:
> > 
> > Marc Hadley wrote:
> >> 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.
> >>
> > 
> > I was not suggesting that the receiver not follow the SOAP processing 
> > model. The non-WSRX headers in the example above are indeed processed, 

> > but they are processed after 202 is sent back. The SOAP processing 
model 
> > does not impose any header processing order. There are several ways 
the 
> > receiver can process the message while staying within the processing 
> > model. HTTP 202 status code is intentionally non-committal. The 
question 
> > I think we should consider is: do we want to restrict when the 202 
gets 
> > sent. Some examples/scenarios of when 202 could be sent:
> > 
> > 1) receiver sends 202 after all the bytes are received correctly (with 

> > the right HTTP headers/media type), >>but before the SOAP message is 
> > processed at all<<. The message gets stored in some message store. 
Batch 
> > processing of all messages is done once per day. If there is a fault 
> > that is generated it is sent to wsa:FaultTo. If there is reply to be 
> > sent, it is sent to wsa:ReplyTo. Both wsa:FaultTo and wsa:ReplyTo are 
> > non-anonymous.

I think that this is making some dangerous assumptions, that the 
wsa:ReplyTo
and wsa:FaultTo are non-anonymous. Wouldn't it be required to KNOW that 
with
some certainty? e.g. wouldn't the SOAP processing, at least as far as 
inspecting
the message to ENSURE that were the case, need to be performed? What if 
the
wsa:ReplyTo and/or wsa:FaultTo *were* anonymous? (oops). For that matter,
what if they had been omitted altogether (after all, they are not 
required).

Shouldn't the message at least be scanned to ensure that it is in fact 
the correct version of SOAP?

> > 
> > 2) receiver sends 202 after all the bytes are received correctly (with 

> > the right HTTP headers/media type), >>and after all the MU processing 
> > (check to ensure that all MU=1 headers are understood, else generating 

> > MU fault) is done, but before the headers and body are processed<<. 
The 
> > message gets stored in some message store. Batch processing of all 
> > messages is done once per day. If there is a fault that is generated 
it 
> > is sent to wsa:FaultTo. If there is reply to be sent, it is sent to 
> > wsa:ReplyTo. Both wsa:FaultTo and wsa:ReplyTo are non-anonymous.

Again, see above. This gets a little closer to what I would expect. 
Whether
the headers are *processed* or just inspected (e.g. for mU purposes as 
well
as to ensure that the wsa:ReplyTo and/or wsa:FaultTo are non-anonymous). 
Clearly,
if they are anonymous or omitted (which I believe means that they default 
to 
anonymous) then the message would need to be *processed* rather than
stored for subsequent batch processing.

> > 
> > 3) receiver sends 202 after all the bytes are received correctly (with 

> > the right HTTP headers/media type), >>and after all the MU processing 
> > (check to ensure that all MU=1 headers are understood, else generate 
MU 
> > fault) is done and after the headers are processed<<. The message 
(with 
> > only soap body and no headers) gets stored in some message store. 
Batch 
> > processing of all messages is done once per day. If there is fault 
that 
> > is generated that is sent to wsa:FaultTo. If there is reply to be 
sent, 
> > it is sent to wsa:ReplyTo. Both wsa:FaultTo and wsa:ReplyTo are 
> > non-anonymous.
> > 
> > 4) receiver sends 202 after all the bytes are received correctly (with 

> > the right HTTP headers/media type), >>and after all the MU processing 
> > (check to ensure that all MU=1 headers are understood, else generate 
MU 
> > fault) is done and after the headers and body are processed<<.
> > 
> > Are you suggesting that only (2), (3) and (4) should be allowed but 
not 
> > (1)? The way I see it, I don't see why (1) should not be allowed -- we 

> > are after all trying to do a "one-way" over HTTP and 202 is 
> > intentionally non-committal (wrt the processing of the received 
> > message). IOW, what can the sender assume when it gets back a 202? I 
> > would say: not much other than the fact that the bytes were correctly 
> > transmitted/transfered.

I tend to agree with Marc. Something part way between (2) and (3) is 
warranted.
I don't think (1) is valid. Certainly, (1) is making some pretty dangerous 
assumptions.


> > 
> > Comments?
> > 
> The main use case I've heard is to allow WS-RX acks to be sent on the 
> HTTP response even when the actual SOAP response message is conveyed in 
> some other way. For this use case I don't think (1) is valid since it 
> involves some WS-RX header processing. For this use case I think that 
> something part way between 2 and 3 is being suggested, i.e. the mU check 

> is done and the WS-RX headers are processed but not necessarily all of 
> the headers. From a WS-Addr perspective it would be good to define 
> whether WS-A header are processed before the WS-RX ack is sent so a 
> sender can know whether to expect WS-A MAPs in the WS-RX ack message or 
not.
> 
> My main concern is that whatever scheme we come up with is consistent 
> with the SOAP processing model and deterministic. I.e. a sender needs to 

> know what steps are going to be taken by a receiver before any kind of 
> response or ack message is generated
> 
> Marc.
> 
> 
>