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

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