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

Received on Friday, 10 January 2003 17:26:20 UTC