W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

RE: Proposed text on reliability in the web services architecture [long]

From: Peter Furniss <peter.furniss@choreology.com>
Date: Thu, 9 Jan 2003 16:50:29 -0000
To: "Walden Mathews" <waldenm@optonline.net>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, <www-ws-arch@w3.org>
Message-ID: <AFEGLEPPBAJOMLIADGFOMECHCJAA.peter.furniss@choreology.com>

> > Yes please.  If Mike's description here of the approach is on the right
> > lines, it would seem
> > to run the risk of holding the form of REST but denying the substance.
> There
> > could be more
> > statefulness here, and held for longer than in the other approaches.
> Making
> > a URI-distinguished
> > resource to hold what is really session state (relevant only to the
> > particular client that requested
> > the update) doesn't seem to gain much in reality.
> It's not about holding session state longer.  Assuming a client is
> communicating because it wants to change the state of a resource,
> then the goal of that activity is the resource in some new state.
> Focusing on that problem, REST provides generic methods for
> safely sampling result states (GET) and for directly specifying
> desired end states (PUT), avoiding the risk of multiple-delta application
> (a/k/a "idempotence").

this is fine if the client knows what the future state should be. What if
it only knows what it wants done (e.g. buy a wotsit - and the client
buys several wotsits a day). Then session(or invocation) specific resources
identifiers are going to be needed.

>     Addressing the goals directly is an important
> simplifying abstraction.  Cf. the client trying to figure out how many
> update requests are still alive in the network and trying to kill all
> the ones it doesn't want to be applied.

> These capabilities are needed regardless of what comms stack
> you have.  It's the meaning of "reliability" at the applications layer.
> Regardless of the "reliability" level in the stack, if an application is
> written without regard for this end-to-end view of resource state,
> it is not "reliable".

I agree.

Received on Thursday, 9 January 2003 11:52:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC