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

Anish Karamarkar writes:

> I agree that one doesn't get req/resp out of merely sending one
> transport-level message over a transport that is FAF. Perhaps 
> we are talking about the same thing here. Not sure.

My point is that you don't even get typical req/resp behavior out of two 
one way messages, one outbound and one inbound.  FAF is usually 
implemented as a single packet, in the absence of fragmentation, all the 
way down to the wire level.  As you can see from studying the 
implementation of HTTP over TCP/IP, the request/response semantics we're 
used to depend on way more than one packet in each direction at the 
transport level.  The two are just different.  What's confusing people is 
that it's tempting not to look inside what's going on at the HTTP & TCP/IP 
levels, and the requirements those put on you for waiting for a response 
in the case of request/response.

> What I was trying to say was that when we talk about MEP 
> abstractions, it is perfectly possible to layer one-way MEP 
> abstraction over inherently req-res transports (because the 
> layer that deals with the MEP does not see or is aware of the 
> transport level response). Similarly, it is also possible to do
> a R-R MEP over FAF transports such as UDP/SMTP, by using 
> additional transport level constructs (or SOAP headers) -- the 
> transport binding for the MEP can certainly require 
> blocking/retransmission of the transport level messages till a 
> response is received.

My concern is whether this is really honoring the "forget" in 
"fire-and-forget".  It's really best described as 
"fire-and-waitForButDontprocessDetailsOfResponse".  For the reasons stated 
in Patrick McManus' note [1], firing and >forgetting< is a bug on HTTP 
over TCP/IP.  In particular, firing and immediately closing the connection 
causes problems with HTTP proxies, among other things.

Several people have pointed out that you can to some degree hide the 
"waitForButDontprocessDetailsOfResponse" under a wrapper API.  This is 
true insofar as you ignore timing and application shutdown concerns. 
Question:  if you code:

        ...
        fireAndForget(msg);
        exit(0);

will your application terminate promptly if run over HTTP?  Will it 
terminate roughly as promptly when implemented in the manner you suggest 
as it would in the case of a true datagram protocol such as UDP?  The 
request/response nature of the transport abstraction visibly leaks in 
terms of timing, even though the apparent signature of fireAndForget(msg) 
is the right one.  In practice, at least in certain implementations, that 
API is likely to have side effects that linger after its seeming return. 
At least some piece of code needs to stay around waiting for the response, 
and in some systems that will be hard to do after the application exits. 

Once again, I'm not convinced.  I continue to believe that FAF as quite 
deeply different from Req/Resp.  I'm not in all cases against simulating a 
one way message over an r/r transport by hiding the 
"waitForButDontprocessDetailsOfResponse", but it's probably not usually a 
good think to do.  I'd rather be honest and call it:

        sendMessageandIgnoreResponse(msg);
        exit(0);

That makes clear what's happening, and it's easily implemented as a 
wrapper API on our Request/Response MEP.

Bottom line:  use a one-way FAF MEP on true datagram transports and 
sometimes on reliable queuing systems;  use req/response or response-only 
on true r/r transports.


[1]  http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0139.html
--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 8 February 2006 15:38:54 UTC