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

OK, so here are the constraints:

    * I want to send a message to some intermittently connected device.
    * I would like acknowledgment when the message finally arrives.
    * This acknowledgment needs to be asynchronous.  I cannot keep a
      connection open until the destination device decides to come back
      on line.

Questions:

    * What transfer protocol would you suggest for this?  HTTP, SMTP,
      FTP etc. clearly don't solve this problem and aren't intended to.
    * What problems do you see in building a solution on top of *TP? 
      Specifically
          o Use <your favorite transfer protocol> to put the message
            into a buffer somewhere.  It would be polite for the
            transfer protocol to acknowledge that the message was
            received and queued, but it's not strictly necessary.
          o When it's on line and in the mood to retrieve messages, the
            destination device uses <some transfer protocol it likes> to
            pull messages out of the buffer.
          o Either the destination device or the buffer uses <a suitable
            transfer protocol> to send me an acknowledgment when this
            happens.

This seems quite a bit like using return receipt with email.  Notably,
doing so works regardless of whether I'm using raw UUCP, SMTP, POP, IMAP
or a carrier pigeon with a USB drive to get email.  The same concept
even works with snail mail (no surprise).

Mark Baker wrote:

>David,
>
>On 1/5/06, David Hull <dmh@tibco.com> wrote:
>  
>
>> Mark,
>>
>> Sorry to have caused bleeding or other discomfort, but no matter how
>>ironclad HTTP may be
>>    
>>
>
>I don't recall making any claim about HTTP being "ironclad".  In fact,
>I only used HTTP as an example in my last message.  What I did say
>though, is that you appear to require a transfer protocol (i.e.
>something that provides application layer acknowledgement semantics of
>document delivery), yet rather than using HTTP or other transfer
>protocols (SMTP, FTP, ...) *as* transfer protocols, you're instead
>treating them as transport protocols and then building a new transfer
>protocol layer on top.
>
>  
>
>> 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).
>>    
>>
>
>I'm saying that transfer protocols *are* paint can openers.
>
>  
>
>> 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.
>>    
>>
>
>Quite the contrary.  It would most definitely be a problem for most
>HTTP intermediaries, including firewalls and caches, because they rely
>on the ordered, implicit correlation of request & responses to
>guarantee correct behaviour for the tasks they perform (for better and
>worse).  For example, a cache uses the URI in a GET request as part of
>the key to store the representation returned in the corresponding
>response, where the correlation between request and response assumes
>ordering.  So if responses started arriving out-of-order, caches would
>cease to function correctly as they would return erroneous responses.
>
>  
>
>> Personally, I don't have a problem with using something that happens to
>>work well as a transfer protocol in a particular area (synchronous
>>request-response) as a transport 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.
>>    
>>
>
>Yes, and HTTP (and other transfer protocols) can signal a variety of
>different kinds of successful (and otherwise) *delivery* semantics.
>
>  
>
>> 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.
>>    
>>
>
>As most transfer protocols (including HTTP) do, by providing a
>reasonable rich set of response semantics, but also by allowing for
>response code extensions.  For example, an HTTP 202 response would
>make a good response to your "queued" example above.  No need to treat
>it as a transport protocol.
>
>And BTW, the SOAP 1.2 HTTP binding does say[1] "This binding of SOAP
>to HTTP is intended to make appropriate use of HTTP as an application
>protocol", so I hope that continues to be the case (a quick glance
>through DaveO's work suggests it is, but a "diff" document would be
>nice to tell for sure).
>
> [1] http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#httpuse
>
>Mark.
>--
>Mark Baker.  Ottawa, Ontario, CANADA.       http://www.markbaker.ca
>Coactus; Web-inspired integration strategies  http://www.coactus.com
>
>  
>