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

[Dan Weinreb <dlw@exceloncorp.com>]

   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.