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

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
--------------------------------------

Received on Wednesday, 25 January 2006 13:48:32 UTC