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

What we find out is that a lot of business apps have idempotent processing
for messages. That is, if you post the same message twice (PUT or POST) they
will only process it once. What they don't have is client-managed state
transfer.

In other words, the client expresses the intent to change a state from X to
Y. The application intends to fulfill that request but may find that a) the
state transfer is not possible b) there are Y1 and Y2 states which it could
end transferring to c) there is a Z state that it could end transferring to.

Cancelling a purchase order is a good example. The client requests a state
change from pending to cancelled. The client typically identifies that the
state is pending, but when the requests gets to be processed it might
already be shipping. So the state transfer may or may not happen.
Furthermore, up to some point you can cancel without any side effects, but
at some point you may be charged for cost incurred by the seller (e.g. if
you are buying a special-order product). So you have Y1 to represent
cancelled no charge, and Y2 to represent cancelled but deposit not refunded.

In either case don't count on the result being delivered in time to be part
of the HTTP PUT response. If there's any human intervention required or
asynchronous communication with some other system, you'll be getting the
result of the state transfer in the future.

Whether you use PUT or POST doesn't tell you more or less about the
operation. And if you only look at the operation form the prespective of PUT
or POST you are missing on a rich set of semantics that is specific to that
operation beyond what HTTP tries to capture (the message passing).

This doesn't mean you can't use PUT. It just means that in order to build
business solutions you need to understand more details about the operation
you are performing. PUT is not sufficient. Something more is needed. But
that brings me full circle to the beginning of the discussion. The point
that in order to automate these systems you need to understand what is
actually transpiring, and without a service definition language it's a
try-and-see-what-happens approach, which is not one of my favorites
architecture.

arkin


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Walden Mathews
> Sent: Thursday, January 09, 2003 1:14 PM
> To: Peter Furniss; Champion, Mike; www-ws-arch@w3.org
> Subject: Re: Proposed text on reliability in the web services
> architecture [long]
>
>
>
> > > 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
> > typically
> > buys several wotsits a day). Then session(or invocation) specific
> resources
> > or
> > identifiers are going to be needed.
> >
>
> Maybe, but there are other ways of thinking about it.  For instance,
> if the client knows at the end of the day how many watsits it ordered,
> then an idempotent update to the order seems appropriate.  If the
> client doesn't know or doesn't care how many watsits it ordered, then
> reliability is expensive overkill anyhow.
>
> If the client prefers to maintain n sessions, though, that's its business,
> and it's not bad design, long as it's the client maintaining the sessions,
> not
> the server.  I think we'd find in the real world that the client will
> somehow
> maintain its own record of what it ordered, which constitutes the
> end-state
> info needed to drive an idempotent interaction.
>
> Walden
>

Received on Thursday, 9 January 2003 17:13:50 UTC