Re: Proposed text on reliability in the web services architecture

arkin,

> > > 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]

Ok. "Repeated applications" doesn't mean you reset initial state
prior to each one, though.

>
> 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).

Where I come from, that's called a "function".  If "outcome" space is
limited to one result, it's "deterministic".  Right?

> 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.

Right: indeterminism and reliability are a bad mix.  That's intuitive.

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

That's right, as long as each iteration begins with the post state of the
prior one.  That's what you were missing above when you said "the same
write given the same initial state would always result in the same terminal
state".

Compare these two formulas

(1) f(x) = f(x) = f(x) ... = f(x)
(2) f(x) = f(f(x) = f(f(f(x) ...

The first illustrates "function".  The second illustrates "idempotence".

[Now that I've had coffee and am feeling pedantic, here's another
formula.  Guess what REST method property it illustrates

    (3) f(x) = x]

Does the above clarify?  If initial state is called x, and the post-state of
the first application of the operation "f" is x', then the key to
understanding
the difference between "function" and "idempotent" is that the
latter is saying f(x') = f(x).  No matter that x' and x may be the same
values.

>
> 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.

Not sure about "obvious".  You have to design it that way.  The system
"works" when an application from any state from x' on is a no-op, with the
understanding that those states are all identical, but (usually) distinct
from
initial state x.

["safe"] - did you guess?

Walden

Received on Friday, 10 January 2003 09:36:16 UTC