RE: Proposed text on reliability in the web services architecture

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Friday, January 10, 2003 7:20 PM
> To: Assaf Arkin; Peter Furniss; Champion, Mike; www-ws-arch@w3.org
> Subject: 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.

Consider depositing funds. You can do that by:

1. Sending the end-state
2. Sending the pre-state+part end-state
3. Sending a delta (the amount to deposit)

In order to perform a deposit all you need is to send the delta, you don't
need to know what the pre-state is.

In order to send the end-state you need to know more than the balance. In
fact, when you make a deposit two states are changed: 1) the balance, 2) the
journal (where every change is recorded).

So the end-state is a composition of the new balance and the journal which
now contains a new record. It's not practical to send the full end-state.

However, you can send a partial end-state, just the balance plus a version
number of the balance. That would allow the server to determine whether the
change has been done (based on the version number) and if not change the
end-state by also adding a record in the journal.

So practically you would be looking at either 2 or 3.


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

Yes we do.


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

Here is my understanding so far.

When you can use idempotent operations you should do so. But in some cases
they are impractical and you are better off not doing idempotent operations.

If you are not doing an idempotent operation then you must perform the
operation at most once. You actually plan for exactly once, but that's not
practical either, you need to account for at most once possibility.
Otherwise, I would not be balancing my checks at the end of the month, but
even big banks are known to make mistakes.

If you are sending a message and know whether the message has been sent with
99.99% success rate (i.e. only in 0.01% of cases you need to somehow resolve
the situation) then you are fine.

If you are sending a message and do not immediately know whether the message
has been sent, and the success ration is 90% (e.g. when you use IP multicast
or UDP or SMTP) then you need to resolve 10% of the time.

You can reduce that to 0.01% (or something like that, my numbers are all
made up) if you have some messaging layer that makes the messages idempotent
and keep resending until it gets close to 100% of success rate.

So reliable messaging buys you:

- Operation is idempotent or not idempotent, it works the same way
- You can use a high latency non-reliable messaging exchange
- The success rate gets as close to 100% as possible
- The layer is reusable and works the same way for all applications without
complicating the application

arkin

>
> Walden
>

Received on Tuesday, 14 January 2003 21:22:48 UTC