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

Mark,

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.

This may not be glatt kosher, but failure to conform to a given paradigm
does not preclude a  pattern from being useful.  If I have a can of
paint I need opened and I'm sitting in a room full of screwdrivers, I'm
going to use a screwdriver and not make a trip to the hardware store for
the "right" tool (which does exist).

If the concern is that HTTP is not an appropriate tool for sending a
stream of notifications for which delivery (or transfer, if you prefer)
entails non-trivial processing on the receiving end, then believe me,
I'm sympathetic.  Nonetheless, SOAP/HTTP seems quite capable of handling
the task.  The only problem appears to be that the resulting SOAP
"request" and "response" messages aren't correlated in the usual manner

This problem, if it is a problem at all, is of no concern to anything
that just looks at HTTP.  Such an entity will see POSTs and responses
and be none the wiser.  One could object that this has practically
nothing to do with "accept[ing] the entity enclosed in the request as a
new subordinate of the resource identified by the Request-URI", but that
train left the station some time ago.

Personally, I don't have a problem with using something that happens to
work well as a trans/fer/ protocol in a particular area (synchronous
request-response) as a trans/port/ protocol in the larger context of
message-based distributed processing.  If that's abuse of notation,
protocol or both, I'll return to the original point:  Whether successful
transmission implies successful delivery depends on how you define
delivery or, equivalently, what you assert that you're acknowledging.

If you're ACKing "I got the message", then you don't need to do anything
special.  Use POST to transfer the message.  If you're ACKing "I got the
message and queued it for processing," it's almost certainly still OK to
hold the HTTP response until the message is queued.  If you're ACKing "I
got the message, established that the cell phone it's ultimately going
to was in range, and then made sure that it got to said phone," then
holding up the response may not be such a good idea.  Given the fluid
nature of the boundary between OK to hold up the response and not OK, it
seems useful to allow the same protocol to serve for both cases.

Mark Baker wrote:

>On 1/4/06, David Hull <dmh@tibco.com> wrote:
>  
>
>> The reliability standards I've seen distinguish between submit/deliver and
>>transmit/receive.
>>    
>>
>
>i.e. they distinguish between transfer and transport (respectively).
>
>  
>
>> The upshot here is that, even if I use a TCP-based transport, and even if
>>that transport allows for status codes or some other indication of a
>>successful exchange, successful transmission of a message does not imply
>>successful delivery.
>>    
>>
>
>If it's a transfer protocol, that's *exactly* what it implies.
>
>Sorry for my terseness, but I'm simultaneously bleeding from the ears,
>pulling out my hair, and gritting my teeth, wondering why oh why folks
>continue to treat application protocols like HTTP as transport
>protocols, when what you clearly need *is* a transfer protocol!!
>
>Mark.
>--
>Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
>Coactus; Web-inspired integration strategies  http://www.coactus.com
>
>  
>