Re: Request-response and addressing

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 Wednesday, 18 January 2006 22:05:48 UTC