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

David,

I would only point out that this largely depends upon what layer is doing 
the
"forgetting". I could have an API that looks like a true FAF that 
under-the-covers
spawns a thread that sends a req/resp over HTTP, waits for the HTTP 
response
and then kills the thread. From the pespective of the code above that API,
it is a true FAF.

        void FAF(SOAPEnvelope message);

For that matter, as someone pointed out in an earlier missive, you could
also do the reverse over a FAF protocol, with messages travelling in
each direction such that the under-the-covers the binding layer opens
a port to receive a response, spawns a thread to send the message as a FAF 
and then
correlates the response and returns it to the abstraction layer that 
thinks
it is request/response.

        SOAPEnvelope RequestResponse(SOAP request) throws Exception;

For that matter, the RequestResponse above could have been effected using
two separate request/resonse exchanges, with the first request's response
providing a HTTP 303 Redirect that triggered a separate HTTP GET to 
the redirected URI to retrieve the actual response to the original 
request.
The application code above the API is oblivious to the machinations of the
layers below it, as should be the case. 

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

xml-dist-app-request@w3.org wrote on 01/26/2006 06:13:38 PM:

> 
> 
> 
> > -----Original Message-----
> > From: Rich Salz [mailto:rsalz@datapower.com]
> > Sent: Monday, January 23, 2006 9:08 PM
> > To: David Orchard
> > Cc: xml-dist-app@w3.org
> > Subject: RE: The deep difference between request/response and
> fire-and-
> > forget
> > 
> > > I would say that if closing the connection (wow, I originally typed
> that
> > > as if close thing connection..) without waiting for a response is
> > > invalid HTTP, THEN that means that HTTP can't do Fire and Forget AND
> > > that an application that would be built on Fire and Forget couldn't
> be
> > > deployed on HTTP.
> > 
> > I'm not so sure.  Why can't you do HTTP/FaF by saying that the HTTP
> server
> > response is consumed (per the HTTP protocol spec) but ignored?
> 
> I would think that consuming the response is the opposite of "forget".
> Consuming the response is effectively not fire and forget.  Isn't that
> the key difference between req/resp and f-a-f?
> 
> Dave
>