Re: Proposed text on reliability in the web services architecture

> While these are good points to make in the WSA document, there are some
> downsides that must be noted:

Or, possibly, debunked.

>
> * It's not clear how this would work in an environment where messages span
> different protocols, which may not have the fine-grained and well-defined
> error reporting and redirection features of HTTP.

Because of the ambiguity of "messages span different protocols", could you
please provide one or more scenarios for clarification?

>
> * It requires the web service system to be designed from the ground up to
be
> RESTful; it's hard to see how legacy procedural code can, in general, be
> wrapped up in a layer that exposes it using the resource/representation
> framework, makes updates idempotent, etc.

No "ground up" redesign necessary.  Why is that hard to see?

>
> * It forces application developers to think about transport issues much
more
> than they generally want to. There's a middle ground between hiding the
> unreliable infrastructure behind "magic" IDEs and protocols and making
> application developers be aware of all the complex issues involved in
> distributed computing.

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.

Application developers need only be aware of the "complex issue" of
knowing what state their application is currently in and what has to happen
to get it to the next state.  It's not about the complexity of, say, a TCP
stack.  The application developer's burden is considerably lighter.

Walden

Received on Thursday, 9 January 2003 09:04:40 UTC