Re: Proposed text on reliability in the web services architecture

Mike,

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

Okay.

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

That confuses me some.  I assume that by "non-RPC Web services" you
mean applications, so their "error notification capability" must be at the
application layer.  What that has to do with WS-Reliability or WS-Transact
I don't get.

> and simply forces the application to
> deal with indeterminate status codes, asynchronous notification of
> success/failure, two-phase commit protocols, or whatever.

Now I'm baffled, because those things sound like a pain in
the arse, not a "good thing".

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

Not sure about his example, but I believe we've established
today that wrapping a legacy application is an easy and effective
way to avoid a "ground up" redesign.  If not, please advise.

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

As an open-ended task, that's a bear.  Do we have a set of "reliability"
use cases laying around as a starting place?  If not, can we get some?

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

Addressed this above, but I'd like to hear from you where we stand
on it.

Walden