Re: SOAP 1.1 One-way HTTP Binding doc

One comment inlined below.

-Anish
--

Christopher B Ferris wrote:
> 
> 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).
> 

The service may have advertised it through its WSDL that anon 
replyto/faultto are not allowed and expects the clients/requesters to 
follow those rules. If they don't, then the client will not get the 
expected semantics. But given the non-committal nature of 202, the 
client does not know that the request has been processed anyway.

I guess the question is: do we want to allow "one-way" messages on HTTP, 
  with a back-channel (HTTP response) which allows the service to push 
*unrelated* SOAP messages back to the requester. By "one-way", I mean 
the requester has no idea of the status of whether the message has been 
processed or not (even MU processing) -- the safe assumption being that 
the service has only received the bytes.

Chris/Marc: are you suggesting that we make the new MEP/binding impose 
processing order wrt WS-Addressing headers and make the binding 
dependent on ws-addressing?

-Anish
--

> 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.
>  >
>  >
>  >

Received on Monday, 6 February 2006 20:20:35 UTC