W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2001

RE: mustUnderstand on client side

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Wed, 2 May 2001 08:52:16 -0700
To: <Noah_Mendelsohn@lotus.com>
Cc: <dick@8760.com>, <xml-dist-app@w3.org>
Message-ID: <79107D208BA38C45A4E45F62673A434D0297CBB6@red-msg-07.redmond.corp.microsoft.com>

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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:13 UTC