RE: "Reliable" web services for Next Big Thing?

> Yup. This is another one of those densely interconnected
> clusters of issues (sortof like "choreography"): "Asynchrony"
> is associated with it (without a reliable substrate, senders
> and receivers can talk "out of band" to ensure that messages
> were received), it's tangled up with Coordination and Transactions
> because Web service invocations can fail for all sorts of reasons
> besides messages not being delivered,  and we are sure to hear 
> from the RESTifarians that the whole idea of supporting reliability
> in the infrastructure rather than the application is counter 
> to the One True Web Architecture. 

I don't have too much to offer this discussion, but I'd like to
chime in to make at least one point.

The idea that reliability in the infrastructure doesn't scale
up well is not peculiar to RESTifarians.  I came gradually to that
conclusion over several years working with distributed market
data, long before I knew anything about Web or REST.  A couple of
examples:

    - Our workstation product always had built-in retry protocol
      at the application level, no matter what substrate it was
      communicating over, and it's plainly obvious that even if it
      uses TCP/IP, the eventual loss of connection places the
      burden of being a good "user agent" back on the application
      layer in the hypothetical stack.  No way out of that if
      you want to be nice to your customer.

    - I made the design mistake of a lifetime when managing
      ticker plant development.  We needed to arbitrate between
      redundant feeds, and chose to do it in the infrastructure
      instead of the application layer.  Woe is me.  We ended up
      implementing a sliding window protocol, introducing
      unavoidable latency and still falling short of the full
      requirement, all because we were focused on a "reliable
      stream" instead of a "recoverable repository".  Hindsight
      is 20/20.  Just sticking records in a database and filling
      the gaps out of band would have been both easier and a 
      better functioning solution.

This has little to do with REST, according to my experience, so
it might be helpful in a political way to decouple.

Thanks,

Walden Mathews
Thomson Financial
(212) 510-3121

Received on Thursday, 5 December 2002 11:37:36 UTC