RE: Summing up on visibility(?)

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of S. Mike Dierken
> Sent: Friday, January 10, 2003 3:56 PM
> To: www-ws-arch@w3.org
> Subject: Re: Summing up on visibility(?)
>
>
>
>
> ----- Original Message -----
> From: "Assaf Arkin" <arkin@intalio.com>
>
> > From what I know if an operation is not idempotent than nothing can make
> it
> > idempotent.
> Perhaps a new idempotent operation can be constructed that uses the
> non-idempotent operation.

Yes.

If your goal is to make all operations idempotent that can be achieved.

If your goal is to build a scalable reliable solution than you need to
decouple the client from the server. Idempotent operations help, the more of
them you can have the better. However, recasting a non-idempotent operation
as idempotent may complicate the client (I've illustrated this before).

So the optimal solution from the perspective of scalability and reliability
will contain as many idempotent operations as possible (sometimes by
recasting) but will also contain many non-idempotent operations.


> > However, you can allow an invocation to be idempotent by
> > allowing multiple instances of the same invocation and detecting and
> > eliminating duplicates. The operation is still not idempotent
> (it has not
> > changed) but the interface allows idempotent invocation.
> This is true. It also has the characteristic of reflecting the original
> operation's non-idempotency - no new semantics.

This solution however does not make the operation idempotent. Instead, it
lets the messaging layer offer idempotent invocations which is necessary if
you cannot determine whether an operation has been performed or not (e.g.
for retrying it).

That is something that reliable messaging offers and also something that
reliable messaging demands.

Which is why I think Web services need to offer reliable messaging.

arkin

Received on Tuesday, 14 January 2003 22:41:42 UTC