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

[email protected] 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
>--------------------------------------
>
>
>
>
>
>
>  
>