Re: Action Item - Part I: WSRX and MEP signaling on the wire

noah_mendelsohn@us.ibm.com wrote:

>David Hull writes:
>
>  
>
>>Sorry to have caused bleeding or other discomfort, but no 
>>matter how ironclad HTTP may be, and no matter what kind of 
>>protocol we decide to call it, there will be situations in 
>>which a given HTTP operation is only part of the story.  If we 
>>consider such situations, then whether HTTP has transported or 
>>transfered a message seems moot.  For the record, I would tend 
>>to agree that in the case I describe we are using a transfer 
>>protocol for transport.
>>    
>>
>
>I think there are indeed times when using HTTP in a tunneled manner may be 
>a necessary evil, but the tone of your note seems to de-emphasize the 
>downsides.  It is reasonable, IMO, for HTTP aware software to assume in 
>general that the semantics of an HTTP interaction are what the spec says. 
>I believe it's a fair reading of the HTTP spec. that the response you 
>receive is indeed to be semantically a response to the corresponding 
>request. 
>  
>
I'm not trying to take a strong position on what might or might not be
advisable other than pushing back against an overly strict
interpretation of what's permitted.

Personally, I try to avoid questions of whether requests and responses
are semantically related and concentrate on what processors /do/,
particularly which messages flow where and whether interop problems are
likely to occur.  In the present case, it seems perfectly legitimate to
think of the HTTP (or *TP) client and server as mailbox resources, with
the client POSTing "here's what I've got for you at the moment, what do
you have for me?" and the server responding "here's what I've got for you".

I'm really hard pressed to see how this deviates materially from the
usual request-response paradigm.  In particular, all the usual caching,
routing, forwarding etc. should work just fine.  Caching will be limited
by the inherently mutable state involved, but this is nothing new.

The wrinkle is that there is more going on on top of the low-level
exchange of messages, but again, this is nothing new.  I might decide
ahead of time to get my balance and post a payment based on what I have
available.  To me, this is one operation, but to the computers involved
it's two or more.  There's no problem so long as the lower-level
transfer/transport/whatever machinery doesn't have to know about the
higher-level activity.  This is why I tend to focus on messages more
than (other) semantics.  The semantics is typically multivalent, while
the message flow is unambiguous.

>You are right that one can imagine a useful class of software that will 
>indeed do useful things when this invariant is violated.  There may indeed 
>be times when async streams resulting, e.g., from reliable message flows 
>can be useful tunneled over multiple HTTP connections.  That said, I think 
>that we should approach such practice with great hesitancy.  Almost surely 
>some of the useful characteristics of HTTP will be compromised, at least 
>in terms of one's ability to use arbitrary HTTP aware tools (certainly 
>logging and management software is likely to give misleading reports about 
>the state of a "Request"). 
>  
>
See above.  IMO the problem is one of keeping the layers properly
separated.  For example, if I'm doing some sort of application-level
request-response operation between myself and an intermittently
connected device, I'll want to build it out of two one-way messages
(just like it says in WSA :-).  Sending the application-level request
might result in multiple HTTP request-response operations (e.g., one for
me to put the request in a buffer, one for the device to pull it out).

Each of these /really is/ a legitimate HTTP request-response, and
proxies etc. will and should treat them as such.  The application-level
request is an entirely separate entity.  Proxies and such cannot, will
not and should not know anything about it.  Everything will work equally
well if the message from me to the other device is a one-way
notification, or whatever else it may be.

As a corollary, when building on top of such a scheme, one cannot assume
any more than that messages can be transferred reliably over one hop (or
a failure signaled).  This allows the usual infrastructure to work as it
always does.

As far as I can tell, this is the whole point of pulling things like
addressing, acknowledgment protocols and security up into the SOAP
envelope in the first place.  The *TP protocols provide suspiciously
similar functionality, but aimed at a different target.  The higher
levels may well include structures very similar to those in the *TP
protocols (or even TCP or IP), but this is just because there are only
so many ways to skin a cat.

>So, I don't think the difference is "moot" at all.  I think it's a crucial 
>difference.  I also think that in some cases one may find that using HTTP 
>as a transport is an appropriate compromise, but certainly not an entirely 
>happy one.
>
>Also, one other thing:  it is a nice characteristic of application-level 
>Request/Response that receipt of the response does give you reliable 
>acknowledgement that all levels of the software have worked, that the 
>application has indeed been invoked, and in the absence of bugs, that the 
>response is authoritative.  I read your note as implying that each level 
>requires its own notion of reliability.  The end-to-end argument [1,2,3] 
>suggests that not to be true in all cases.  (BTW: as I've mentioned once 
>or twice in the past, [2] is about my all time favorite CS paper.  Highly 
>recommended.)
>
>  
>
My take is that each level requires its own /notion/ of reliability, but
that different notions may well be realized by the same mechanism (e.g.,
application-level request-reply using HTTP, where success of the HTTP
transfer is also success at the application level).  Separating the
/notions/ allows for the /realizations/ to be separated when need be,
but does not require it.

I'll have a look at the references in any case.  Thanks.

>Noah
>
>[1] http://portal.acm.org/citation.cfm?id=357402
>[2] http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>[3] http://web.mit.edu/Saltzer/www/publications/endtoend/ANe2ecomment.html
>
>--------------------------------------
>Noah Mendelsohn 
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>
>  
>