RE: Proposed text on reliability in the web services architecture

I agree.

Posit: we have to network access to an existing application. The operations
on the application (via the existing, internal access) are not idempotent.
But, seeking REST, we want to make the networked operations idempotent. So
the client is required to add an identifier of its own invention to the
message - a repeat of the message is thus defined as being one with the same
identifier. The client must remember the identifier for as long as it is
trying send the same request. And the service must remember received
identifiers until it is sure the request won't be repeated.

oh - we've just re-invented the mechanisms used in RM or BTP and their
equivalents. Needs a bit of tidying up to sort out the service-side garbage
collection. And we've got all the retry and recovery stuff as the user
application's responsibility instead of pushing it into the infrastructure
(which may include application protocols from a layer-counting perspective,
but is somebody eles's implementation problem)

Peter

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: 09 January 2003 14:33
> To: www-ws-arch@w3.org
> Subject: RE: Proposed text on reliability in the web services
> architecture
>
>
>
>
>
> > -----Original Message-----
> > From: Walden Mathews [mailto:waldenm@optonline.net]
> > Sent: Thursday, January 09, 2003 9:04 AM
> > To: Champion, Mike; www-ws-arch@w3.org
> > 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.
>
>

Received on Thursday, 9 January 2003 10:33:24 UTC