Re: Proposed text on reliability in the web services architecture

Sent earlier today, but for some reason it didn't get delivered:

WM

----- Original Message -----
From: "Walden Mathews" <[email protected]>
To: "Peter Furniss" <[email protected]>; "Champion, Mike"
<[email protected]>; <[email protected]>
Sent: Thursday, January 09, 2003 11:28 AM
Subject: Re: Proposed text on reliability in the web services architecture


> Peter,
>
> > 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 far so good.
>
> > 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.
>
> Nope.  There is another way.  But before getting into that, are we sure
> the legacy app doesn't support idempotent operations?  I hope you're not
> positing that idempotence in interfaces is unusual or scarce.  All
> operations
> that are essentially assignments fit the bill.
>
> Let's say we have a legacy app that keeps track of the number of chart
> windows you're allowed to run on your market data workstation, and
> it only allows you, through its interface, to change that number by adding
> or subtracting, never directly setting the number.
>
> To manufacture an idempotent web interface to this, we will wrap the
> legacy app with some code that is local to and tightly coupled to the
> legacy app.  Being so situated, it has access to critical sections and
> transactions and such.
>
> The existing count, in our scenario is two, but the client wants a total
> of four.  Via the web interface, the client says, in effect "set count to
> four".
> Idempotent.  Note that client doesn't care what the current count is, and
> more importantly, doesn't need to know in order to achieve its goal.
>
> Wrapper code receives "set to four" from client, then it enters a critical
> section or transaction with legacy code in which it
>
>     - reads current quantity : 2
>     - computes difference: 4 - 2 = 2
>     - invokes non-idempotent update: +2
>     - re-reads (new) current quantity: 4.
>
> Finally, the wrapper code returns the appropriate response to the client,
> in this case an indication of success.
>
> The fact that the legacy back end didn't support a "set" operation is
> transparent to the client; no fiddling with sequence numbers and special
> ids or any of that crap.  I would also note that this is easy programming
> on the server side.
>
> Comments?
>
> Walden
>