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

+1 to David's rant:-)

I think to paraphrase in a single sentence adage: "Just because you can, 
doesn't mean you should"

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 10:58:56 AM:

> 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]. 
> <rant>
> For those not on the WSA list, here's my take on leaky abstractions:
> Follow the instructions on the label.  If the abstraction you're 
> using is "a reliable connection with notification of failure," don't
> pretend that the abstraction is "connection which will never fail." 
> I've seen this example in the context of TCP.  If  you use TCP and 
> your code breaks because you don't handle failures, TCP isn't 
> leaking.  Your code is broken.
> You can't effectively implement everything on top of everything. 
> C++ templates turn out to be functionally complete, but if you try 
> to implement 32-bit addition by passing off to a C++ compiler using 
> some unary-based template hack, you can expect poor performance (at 
> least).  That's not because 32-bit addition is a leaky abstraction. 
> It works fine, in constant time, on several different kinds 
> processor.  It's because you tried to put an abstraction on top of 
> the wrong implementation.
> Both of these are simply mismatches between an abstraction and the 
> adjoining layer.
> 
> For completeness, I'll note that Bad Things can always happen.  Your
> RAM chips could get zapped by a cosmic ray and produce a transient 
> parity error, the network could die, North Dakota State could beat 
> Wisconsin (OK, maybe not such a bad thing, but one would have 
> thought it unlikely), or whatever.  In that sense, the second bullet
> point could be "You can't implement anything perfectly on top of 
> anything," and thence "all abstractions leak."
> 
> Fair enough, but the point is that by using abstractions 
> appropriately, you can limit the effects of Bad Things to where if 
> something bad does happen, you've got bigger fish to fry.  If you 
> see breakage in anything less than a disaster, that's not because 
> all abstractions leak, it's because someone's misusing an 
> abstraction somewhere.
> 
> Executive summary: Don't throw up your hands and say "all 
> abstractions leak, oh well."  Find the mismatches and fix them.
> </rant>
> 
> I believe Noah makes much the same point below, albeit much more 
civilly.
> 
> As I've said before [1] much of the present problem comes from 
> trying to overload a single abstraction (request-response or 
> request-optional-response as the case may be) to cover everything. 
> Rather than trying to do that, let's define small, crisp 
> abstractions that capture the properties of the protocols we're 
> using and build on top of those.
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0135.html
> 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
> --------------------------------------
> 
> 
> 
> 
> 
> 
>