[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] Proposed "idempotent" parameter and attribute and CPAelement
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC