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