RE: mustUnderstand on client side

Well stated! I think you bring up an important point in suggesting the
possibility of not just looking at r/r but also include more
conversation style message exchange patterns and even how these might
relate to guaranteed delivery etc. This is not to say that I think we
are to define guaranteed delivery but we have to consider the
composability aspect.

Henrik 

>To paraphrase what I think Henrik is saying (I.e. to make sure 
>we agree), 
>I do think we have reasonably clear semantics in SOAP for 
>mustUnderstand 
>at the client.  They are the same as anywhere else:  get a 
>message with a 
>mustUnderstand header that you don't understand, you (a) don't 
>process the 
>message and (b) generate a fault.  Now, whether the fault is reliably 
>delivered anywhere is not specified, but (a) is really a significant 
>building block.  If a responder sends mustUnderstand then it 
>knows that 
>the message won't be processed if not understood.  In particular 
>deployment scenarios, one could imagine sending the fault 
>back, but then 
>you get into the usual circularity.  What if the fault can't 
>be delivered? 
> How long must the responder stay around waiting for it?  You 
>really are 
>in the realm not of request/response, but conversation with r/r hidden 
>within the conversation.  That is something we might consider as a 
>supported pattern for XMLP, and in that case I think we can specify 
>delivery rules for the client fault.  So, I claim SOAP gives you the 
>building blocks you reasonably need for one scenario or another.

Received on Wednesday, 2 May 2001 11:53:31 UTC