[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
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC