Re: SOAP 1.1 One-way HTTP Binding doc

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.
> 
> 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.
> 
> 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.
> 
> 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 Thursday, 2 February 2006 14:57:15 UTC