Re: Request-response and addressing

What I'm trying to capture here, one way or another, is what happens
when a correctly implemented server falls over through no fault of its
own.  In one case, the client will know about it, in the other case, it
won't.

noah_mendelsohn@us.ibm.com wrote:

>David:  I think this feels a bit backward.  You seem to be saying "there 
>are reasonable things you could do with XMPP <message/> that aren't SOAP 
>Req/Resp because you could decline to ever send the response.  I think 
>that's backward.  The purpose of the binding is not to exploit all 
>possibilities of the underlying transport;  the purpose of the binding to 
>make sure the transport supports what SOAP needs.  Unless DaveO succeeds 
>in convincing us that the entire response in the req/resp MEP should be 
>optional, SOAP requires that a response be sent, even if XMPP doesn't. So, 
>correct applications using the binding >will< send a response.  No 
>problem.   The fact that non-SOAP XMPP applications might not send a 
>response doesn't seem pertinent.
>
>--------------------------------------
>Noah Mendelsohn 
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>
>
>
>
>David Hull <dmh@tibco.com>
>Sent by: xml-dist-app-request@w3.org
>01/18/2006 01:53 AM
> 
>        To:     "xml-dist-app@w3.org" <xml-dist-app@w3.org>
>        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>        Subject:        Request-response and addressing
>
>
>In a recent message [1] on the WSA list, I argued (against myself :-) that 
>the "anonymous" address may not always imply a request-response MEP. Since 
>this was based in part on SOAP/XMPP, I wanted to carry that point back 
>over to this list, pose a few specific questions and follow on with a few 
>more points:
>
>Do we have a definite consensus that the request-response MEP implies more 
>than just correlation of request and response messages?  In particular, do 
>we agree that a request-response MEP terminates with either a response or 
>a failure (implying some reasonable notion of a timeout), while merely 
>sending a message with a return address and request id does not guarantee 
>either a response or a failure?
>
>In reference to SOAP/XMPP in particular, is the <message/> binding really 
>a proper binding of request-response?  It would appear to me that the 
>receiver could successfully receive the request message and then do 
>nothing further.  One could build a timeout mechanism on top of this, but 
>I don't believe one is (or should be) given in the binding supplied.
>
>What I'm driving at here is that "guaranteed response or failure" and 
>"return address" are separate features of underlying protocols. Guaranteed 
>response/failure implies a return address, but not vice versa.  HTTP and 
><iq/> provide both.  Email and <message/> provide return addressing but 
>not guaranteed response/failure.  UDP and at least some flavors of pub/sub 
>provide neither.
>
>To me, this implies that SOAP/HTTP and SOAP/<iq/> should define the 
>request-response MEP (as they do), but SOAP/<message/>, SOAP/Email, 
>SOAP/UDP etc. should not.  Note that this is different from the issue of 
>whether you can do F&F over HTTP, whether using the request-response MEP 
>or not.
>
>It also may help sharpen the boundary between the roles of WSA and XMLP in 
>dealing with the various MEPs.  WSA seems more clearly concerned with, 
>well, addressing, while semantics such as guarantee of response/failure 
>(or lack thereof) are more to do with XMLP.
>
>Finally, it's worth reiterating that addressing of responses and 
>correlation of responses with requests are separate things:
>HTTP uses the bidirectional TCP connection for return addressing and 
>in-order delivery of responses to correlate requests with responses.  In 
>WSA-speak, it needs neither response endpoints nor [message id] to work 
>(which is why we've gotten by without them :-)
>BEEP (as I understand it, not yet having looked at SOAP/BEEP) uses the 
>bidirectional TCP channel for return addressing, but must use an explicit 
>[message id] for correlation, either at the BEEP level or via WSA.
>It's at least logically possible to provide a usable message id at the 
>protocol level but without return addressing.
>Raw UDP provides neither.
>[1] 
>http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0045.html
>
>
>  
>

Received on Thursday, 19 January 2006 17:11:22 UTC