RE: Proposed text on reliability in the web services architecture

> -----Original Message-----
> From: Walden Mathews [mailto:[email protected]]
> Sent: Thursday, January 09, 2003 9:04 AM
> To: Champion, Mike; [email protected]
> Subject: Re: Proposed text on reliability in the web services
> architecture
>
> 
> Network application developers who don't want to think about network
> failures should find a different line of work.  The Waldo 
> paper has been
> cited enough times already.

Well, I've read the Waldo paper several times, most recently last week.
"Hiding the network" by trying to pretend that partial failures don't happen
(e.g., a write occurs but the network dies before the success code can be
propagated) is clearly a Bad Thing and leads to the problems of NFS that he
notes.  I'm merely asserting that there is a middle ground: that non-RPC Web
services that *do* have a rich notion of error notitification can be used in
a way that puts the bulk of the mechanical burden on the infrastructure
(e.g. WS-Reliability or WS-Transact) and simply forces the application to
deal with indeterminate status codes, asynchronous notification of
success/failure, two-phase commit protocols, or whatever.  

Clearly Waldo has a lot to teach us, e.g. about the desirability of
designing systems so that updates are idempotent. I don't follow the
assertion that this doesn't require redesign from the ground up in systems
that weren't designed that way; that's the whole POINT of his NFS example,
no? 

Anyway, as I said in the draft, a clear statement of how RESTful
applications can work well without assuming a reliable infrastructure, and
what are some of the principles of designing robust systems that handle
network failure gracefully (without necessarily assuming any particular
architectural style) would be much appreciated.  Just recall that many of
the use cases for Web services include the integration of applications that
CANNOT be redesigned.  If you can debunk my mistaken assertions that REST
doesn't work for this use case, go for it.