RE: Proposed text on reliability in the web services architecture

> Arkin,
>
> > There's a whole class of distributed algorithms that attempt to address
> > reliability by defining the system as a composition of automata that is
> > based on exactly two operations: read and write. State transitions are
> > client derived. The client uses a read operation to determine
> the current
> > state, and a write operation to change it to a new state, with guarantee
> > that the same write given the same initial state would always result in
> the
> > same terminal state (in other words, all actions are idempotent).
>
> That may be a deterministic finite state machine, but it's not what
> idempotent means.  You should check your definition.  For this discussion,
> it obviously matter... a lot.

Walden,

Perhaps I don't understand correctly. The definition of idempotent is
"repeated applications have the same effect as one", or "Acting as if used
only once, even if used multiple times." [1]

Given the same input the action I describe above would produce the same
output. And you can continually feed it the same input and it will
invariably produce the same output (in their terminology decide on the same
value). That's not an option. For the action to be used in such a system it
needs to observe these restrictions otherwise everything comes tumbling
down.

So if you do it once, twice or n times, you get the same result. Which is
idempotent as far as I understand it.

What you pass in the input is the state (identifier) you start with and any
thing that has to happen to that state (that's how these protocols work).
Obviously it will only work if the action is still at the same state, but if
it's in a different state it would inform you without doing anything. And
you can repreat sending the wrong state identifier and continue getting the
same result.

arkin

[1] http://dictionary.reference.com/search?q=idempotent

>
> Walden
>
>

Received on Friday, 10 January 2003 00:39:04 UTC