OASIS ebXML Messaging Services TC

 View Only

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

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

    Posted 11-15-2001 09:21
       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.