Re: [ebxml-msg] Proposed "idempotent" parameter and attribute and CPAelement

[Martin W Sachs <mwsachs@us.ibm.com>]

But all that adding these definitions does is eliminate the need for
reliable messaging in some obvious cases where re-sending the message is
understood to do no harm.  Is this gain worth the cost in increased
complexity?

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 11/15/2001 09:16:14 AM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

To:    chris.ferris@sun.com
cc:    ebxml-msg@lists.oasis-open.org
Subject:    Re: [ebxml-msg] Proposed "idempotent" parameter and attribute
       and CPA element



   Date: Thu, 15 Nov 2001 08:50:11 -0500
   From: Christopher Ferris <chris.ferris@sun.com>

   The sender of a message cannot really know whether the receiver's
   application/service
   has idempotent semantics, it can only assert whether or not it wants
   these semantics
   to be applied.

What I was assuming is that the *operation* either does or does not
have idempotent semantics.  It's not a choice between alternative
ways that the receiver can process the message.

That is, the quality of idempotency is inherent in the meaning of the
message.  If two partners are doing business, they have to agree not
only on the names of services and actions, but the meanings of each
service/action pair.  Idempotency is part of the meaning.  An
operation that means "the sender tells the receiver that the sender
has 23 units in stock" is inherently idempotent; the classic "debit my
account by $1M" is inherently not idempotent.

Whether an operation is idempotent has nothing to do with the
receiver's choice of how to implement the operation.

If we were talking about a programming language, we would say that
idempotence is part of the signature, the external declaration, of a
procedure or method.  It's part of the definition, not an
implementation decision.

So I was assuming that the sender really *does* always know whether
the operation that it is requesting is an idempotent operation.

If service/action is being used in the way that I would imagine to be
the normal, "intended" use, then any service/action pair would either
be idempotent or not, and so it would be most natural to express
idempotency in the CPA.

The main use case I can see for expressing idempotency in the message
header is if you have some service/action pair that's not really one
operation but many possible operations depending on the contents of
the body.  For example, you might have a service/action pair called
"Do a banking thing", and the payload document might be XML that has
an element called "<command>" whose value might be "tell me the
balance of this account" (idempotent) or "debit this account by $1M"
(not idempotent).

If this view of things is not right, then my whose proposal isn't
appropriate.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>