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

+1. Well said.

We have gone through the same mistakes and learning curve. The
infrastructure that certainly help by encapsulating disconnected
interactions and retries but exception and timeout management has to be
replicated/done at the application level for the reasons highlited by
Walden. Please note that this is true even in the case where you use
SOAP over JMS. We run into this problem in every customer deployment.

Edwin

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

Received on Thursday, 5 December 2002 11:54:54 UTC