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

+1 to all that Noah has said below.

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/25/2006 08:46:30 AM:

> 
> David Orchard writes;
> 
> > 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. 
> 
> Except as proposed by Mark Baker, and others: I.e. wait for the response 

> at the client.  As Patrick McManus points out [1], you're probably 
> carrying more overhead at the client for closing the connection then you 

> might think from the surface syntax of the APIs.
> 
> > To which I conclude this is yet another leaky abstraction. 
> 
> Sure.  The point is not that abstractions shouldn't leak;  they 
> necessarily leak to some degree, as Spolsky said when he set down the 
> "law"[1].  The point is that if your high level abstractions use your 
low 
> level services in the intended manner, it's less likely that the 
> abstractions will leak in a damaging way.  Patrick is pointing out that 
> the low level packet flows that underly TCP and HTTP are optimized for 
the 
> case where HTTP is used in the intended manner, I.e. Request/Response. 
By 
> properly separating Req/Resp from FAF, and using the layers in the 
> intended manner, we greatly reduce the liklihood of "leakage" from 
> low-level TCP packet flows, proxies, etc.
> 
> > I'm strongly against standardizing any MEP that can't be deployed on
> > HTTP.  That would be very very strange to standardize an MEP and not
> > standardize any bindings for that MEP.  It doesn't pass the giggle 
test
> > at all..
> 
> I think you're mixing two things:
> 
> 1) Should all MEPs be intended for use with HTTP?
> 
> Absolutely not.  In fact, the whole reason for MEPs is that SOAP is to 
be 
> usable over a broad range of "transports", and not all of them will 
> comfortably support all MEPs.  However, if we can agree that two or more 

> transports support a one way FAF, for example, then the changes are 
pretty 
> good that the same apps will run on those transports.  So, the whole 
> purpose of MEPs is to have different MEPs supported on different 
bindings, 
> and there's no reason at all from that perspective that HTTP should 
> support one way.  Of course, if you have business reasons for wanting to 

> support one way on HTTP, that's different.  The discussion in this 
thread 
> suggests you can do it, but only insofar as you are willing to have the 
> far end reply with a no content 202 or 204 message, and have the client 
> spin off a thread or use some other means of properly receiving it, so 
> that low level error traffic doesn't confuse proxies, etc.
> 
> 2) Should we define an MEP before there's at least one binding spec'd to 

> use it.
> 
> Perhaps not. I think that's why we didn't do one-way in the first 
version 
> of SOAP 1.2.   David Hull and perhaps others are making the case that it 

> will so obviously be useful to the community that we should put the MEP 
> spec out there.  Either way is fine with me.  I think it's clear that in 

> the particular case of one-way FAF we know the desired MEP semantics 
well 
> enough to risk spec'ing it without doing a binding, should we wish to.
> 
> > Another interesting related question: If it's illegal to close without
> > reading the return HTTP response, does that mean that an HTTP
> > intermediary MUST wait for the next node's response to faithfully pass
> > back? 
> 
> I might need to think more about it, but my initial reaction is: yes, 
HTTP 
> is request/response.
> 
> > Imagine intermediary closes with 202, but next node responds with
> > 200 and body.  If it was legal to close without reading, then an
> > intermediary could interpret the close as signaling that it could also
> > close after sending..
> 
> I could be wrong, but my intuition is that when an HTTP proxy responds 
on 
> behalf of a server, it typically does not also send the request on down 
> the second hop.  So again, a misuse of the HTTP model to even pass the 
> message to the "next node", I would think.
> 
> All these are exposing reasons why req/resp is different than one way, 
and 
> why I think they are best kept separate.
> 
> Noah
> 
> [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
> --------------------------------------
> 
> 
> 
> 
>