Re: Proposed text on reliability in the web services architecture

>
> On the contrary. I know that a lot of operations are idempotent. I just
know
> that not all operations are idempotent. What I need is an architecture
that
> works with both.

No problem.

>
> I also know that some non-idempotent operations can be made idempotent (as
> you proved with a very eloquent example). And I favor idempotent
operations.
> So given such a transformation I could make even more operations
idempotent.

Good.  We're not saying that all operations need to be idempotent, but we
are asserting a relationship between idempotence and reliability, which I
think
is on track.  Reliability is a goal-oriented concept.  How do you know if
something is reliable if you can't measure it against a goal?  Idempotence
is
the means of reaching the goal via a direct communication of that goal.
It's
the "what instead of how" orientation.

>
> But I still know that some operations are non-idempotent. If you can prove
> that every non-idempotent operation can be made idempotent without
shifting
> the problem away, then I could devise an architecture built solely on
> idempotent operations. If you shift the problem away, I would have to
start
> considering cost/benefit.

I think I'll assert that every reliability problem can be expressed as a
goal,
and that goal satisfaction can be more elegantly communicated via idempotent
methods than via lower level accounting of messages in a network, some
of which are duplicated, some of which are lost, etc...

I'll also assert that on every application I've ever worked on, state
changes
can be expressed interchangeably as either

    (1) delta applied to pre-state, or
    (2) direct end-state

and that given pre-state and delta you can compute post-state, and also
that given pre-state and post-state you can compute delta.  These are
basic to the understanding of applications, and so in any working
application, the knowledge of how to do these is always known.

In my experience, the above observations are strong.  I doubt I could
prove it for all applications, or that if I could anyone could understand
the proof.  May I instead propose that anyone who knows a use case
where these assertions fail, please speak up?

Let me summarize the rest of your post: Idempotence is not *always*
available or desirable in every business situation.  We agree.

In this thread we are
talking about a subset of situations in which clients have the need
and means of verifying resource states, that verification of resource
states is an appropriate idiom for expressing "reliability", and that
idempotence is a simple, available and effective means of achieving
verified states (reliability) under internet conditions.

Can we now please relate this back to the RM discussion and see
what if any progress has been made.

Walden

Received on Friday, 10 January 2003 22:20:39 UTC