Re: The deep difference between request/response andfire-and-forget

David Hull writes:

> If you just need to send a message on a best-effort basis, use F&F

Yes, though if you implement it on JMS, WebSphereMQ (the protocol formerly 
known as MQSeries), etc. then that best effort will be mighty reliably 
when compared to another FAF-capable transport such as UDP.   I think that 
one-way works on both.  It's an interesting question whether one should 
bother naming two one way MEPs that differ only in the likelihood of 
delivery in the face of short-term network trouble.  My inclination would 
be to define at most one FAF MEP and leave it as a quality of service of 
the binding what the likelyhood of delivery would be.  I think that such 
an MEP could be well implemented on UDP, JMS/MQ, SMTP, probablky XMPP, and 
probably others.  Indeed, if anyone wanted to use SOAP at a very low level 
and for messages of limited size, I suspect it would be implementable 
directly on IP as well.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








David Hull <dmh@tibco.com>
01/27/2006 11:18 AM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     David Orchard <dorchard@bea.com>, Mark Baker 
<distobj@acm.org>, "Patrick R. McManus" <mcmanus@datapower.com>, Rich Salz 
<rsalz@datapower.com>, xml-dist-app@w3.org
        Subject:        Re: The deep difference between request/response 
andfire-and-forget


noah_mendelsohn@us.ibm.com wrote: 
David Orchard writes:

 
More to the point, I don't see why we'd need an request-optional-
soap-response mep AND a f-a-f mep where f-a-f is interpreted as you 
suggested on the server. 
 

...because when we implement SOAP on true FAF transports like UDP, and 
maybe some flavors of Jabber (I have to go back and look at that) we'll 
want the true FAF MEP and probably not the Req/Resp (I.e. because 
Req/Resp, as we keep reminding ourselves, requires the transport to know 
how to address responses, which in general UDP does not provide.)
As I've argued, I believe that the request-response MEP provides two 
interesting features: correlation and transactionality.  Further, these 
are independent.  You can have a transactional one-way flow (you know that 
either the message arrived or something bad happened), and you can have 
non-transactional request-response (a.k.a. two correlated one-ways).  HTTP 
provides both, and the request-response MEP promises both.  Even with an 
optional response, it promises transactionality, and promises correlation 
if there is a response.  By contrast, F&F would be aimed at 
non-transactional one-way flow.

In summary:
If you just need to send a message on a best-effort basis, use F&F
If you need to send a message and know that it arrived, as we now have it 
framed, you would use request-optional-response but arrange that there 
would not be a response.
If you need to do a request-response on a best-effort basis, use two 
correlated one-ways.  I've suggested using the [return address] feature 
here to cover the various protocols that provide a return address but no 
transactionality
If you need to do a request-response and know that it worked, use the 
request-response MEP.
Unfortunately, the last will only work if you can do everything in one 
operation of the underlying protocol, i.e. a single HTTP operation.  Even 
in the case of "asynchronous request-response" over HTTP, you've lost the 
transactionality.  In this case, HTTP is little different from everything 
else.  You can tell the request arrived, but if you never receive a 
response, you don't know why, or even that there is an error.  The server 
might just be slow.  You can set a timeout, retry etc., but this all has 
to be above the SOAP level.

I'm also concerned about protocols like XMPP <message/>, which provide a 
one-way transactional operation.  That is, IIUC, you can tell whether your 
<message/> arrived or not even if you're not expecting a response.  If we 
model this as F&F, we've lost that information.  If we model it as r-o-r, 
we're implying that <message/> can provide transactional request/response. 
 It can't.  It can do the correlation, but it can't promise 
transactionality.  It might be possible to finesse this particular case by 
using <iq/> if a response is expected and <message/> if not, but then the 
binding would have to figure out whether a response is expected.  I think 
Rich has argued convincingly against this.

  FAF is 
the natural MEP and should be used on one-way transports;  Req/Resp and/or 

Response-only (which is more properly named 
Request/ResponseWithEnvelopeInResponseOnly) are the natural MEPs and 
should be used on Request/Response protocols like HTTP.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Monday, 30 January 2006 19:46:52 UTC