Re: The role of transfer protocols

On 1/6/06, David Hull <dmh@tibco.com> wrote:
>  In the solutions you outline below, what acknowledgment, of what, do I get
> when?
>
>  What I want is acknowledgment that my counterpart on the intermittently
> attached device has received the message I sent (for bonus points, that it
> has received it and done something meaningful with it).
>
>  If I understand your terminology correctly, using HTTP as a transfer
> protocol would mean that I would not get back an HTTP response until my
> counterpart actually received the message, arbitrarily later.  Similarly,
> SMTP would not send back an OK message until the counterpart actually
> received the message.  As I understand it, this is at best bad practice with
> HTTP and simply not what SMTP does at all (if I want to know that someone
> actually got my email, I ask for a return receipt).

Right, that's not what I was saying.

I actually didn't describe a single solution, just outlined some options.

But one solution would be to setup an HTTP gateway for the
intermittently connected device.  Documents would be POSTed to the
gateway, and then the device, when it came online and felt up to it,
would invoke GET to retrieve the documents.  Since GET is safe, the
gateway shouldn't send acknowledgements to the document sender as a
result of that action, but instead the device could send the
acknowledgements after successfully retrieving the documents.

>  The general point is that that *TP can only tell me that something was
> transferred to the server on the other end of the connection.

Not necessarily, as it depends on the protocol.  SMTP, for example, is
hop-by-hop, so when you send an email and receive a 250 response, all
you know is that that node/hop got it, not that the recipient got it.

HTTP has both hop-by-hop and end-to-end features, and can be used in
different configurations too to give it the properties you desire. 
The traditional proxy configuration (e.g. firewall, cache, ...) would
behave as you describe, but a gateway configuration as described above
can be used to further decouple sender and recipient.

But whatever; even if you can't find an existing TP that suits your
needs, you can always develop a new one.  My objective with this
thread is not to convince you to use HTTP or any other TP, it's just
to explain the role of transfer protocols in relation to transport
protocols and the assumed Web services architecture.

[snip]
>  Alternatively, you could define each bid, offer or sale as a document in
> and of itself.  IMHO, this is stretching the notion of document far beyond
> any useful point.  Documents simply live in a different design space from
> notifications.

I don't think that's any stretch at all.  If I showed anybody an XML
document which represented a bid, I doubt I'd find one person who'd be
surprised at hearing it called a document.

>  Document exchange systems are generally aimed at moving reasonably large
> hunks of data around with a premium on reliability and without great regard
> for short and predictable latency.  Event notifications are typically quite
> small.  Something like "machine 3 just caught fire" or "Goldman bids
> $20.25/share for 1000 shares of FooCorp" manifestly takes no more than
> dozens of bytes even without any attempt to remove redundant information.  A
> carefully designed system can deliver dozens of notifications in the packets
> it takes TCP to shake hands (I've seen it done :-).

It seems "document exchange" is overloaded with you, so let's avoid
it.  Perhaps we can use the more precise and generic name "state
transfer".  As I see it, both EDI-style bulk-data-exchange based
systems, and event notification systems, are both state transfer based
systems.

>  Guaranteed delivery of notifications is not always appropriate.  It most
> likely would be for "machine 3 just caught fire", but often with market data
> "old news is no news" and it's better to deliver the most recent information
> quickly than to make sure that old information gets there.  Similarly,
> latency and predictability thereof matter in real-time notification systems.

Absolutely.

You might be interested in Rohit Khare's dissertation, which describes
some architectural styles (REST extensions, interestingly) which are
intended to address issues like you describe, amoungst other related
ones (multi-agency, concensus, ...);

http://www.ics.uci.edu/~rohit/DecentralizingREST.pdf

Mark.

Received on Saturday, 7 January 2006 03:51:37 UTC