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

> -----Original Message-----
> From: Mathews, Walden [mailto:walden.mathews@tfn.com]
> Sent: Thursday, December 05, 2002 11:37 AM
> To: 'Champion, Mike'; www-ws-arch@w3.org
> Subject: RE: "Reliable" web services for Next Big Thing?
> 
> 

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

[Wearing my Software AG (a DBMS vendor) hat, not my WSA co-chair hat]

You may be a RESTifarian without knowing it :-)   I discovered that
I had RESTifarian leanings for exactly this reason -- it seems so
much easier to "stick records in a [shared] database" that has transaction
management, etc. than to worry about all that reliability, routing,
transactionality,
coordination, etc. at the messaging layer.  The Linda / JavaSpaces /
TupleSpaces / XML Spaces stuff seems particularly relevant here.  I believe
that Linda-esque coordination is considered RESTful by the cognoscenti, but
I'm not sure.  (yes, I know, there's a page on this in the REST Wiki ...
I'll read it!)

I do think that the question of how to balance the duties that one can
expect the infrastructure to perform (after all, a DBMS is "infrastructure")
and how much must demand of the application is a very good one however ...
and I personally would like to see the reference architecture be abstract
enough to encompass both message routing/reliability/transactions and DBMS
intermediated messaging.

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