[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
A couple of comments below. MWS: 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/14/2001 11:59:23 PM Please respond to Dan Weinreb <dlw@exceloncorp.com> To: ebxml-msg@lists.oasis-open.org cc: Subject: [ebxml-msg] Proposed "idempotent" parameter and attribute and CPA element Here's the proposal that I said I'd provide: This proposal changes the "duplicateElimination" attribute to the "idempotent" attribute. Note that the sense is reversed; that is, loosely speaking, idempotent being false means the same thing as duplicateElimination being true. Very unfortunately, the current CPA spec has an element called "idempotency", which is TRUE if the message IS NOT idempotent, and FALSE if the message IS idempotent. (The CPA spec uses the phrase "idempotency check" to mean "duplicate check".) We propose that the CPA group change the name of the element to "idempotent", with the sense that the value is true if and only if the message is idempotent. MWS: I agree that the element in the CPA is mis-named. However, the intent was for TRUE to mean that duplicate checking is required. In this sense the element is redundant with the deliverySemantics attribute and could have been eliminated if nothing else changed. MWS: I'm getting the sense that the proposal is tantamount to doing reliable messaging with optional duplicate elimination. That may also be OK but is not onceAndOnlyOnce. So if the deliverySemantics attribute is still alive, some new value is needed for reliable messaging without duplicate elimination. In that case, the idempotency attribute is still redundant and could be eliminated. MWS: All in all, the amount of restructuring taking place in the area of reliable messaging impresses me as being well beyond the scope of a maintenance release and should be deferred to version 2. The following text is proposed to replace sections 3.1 and 7.4.1; in accordance with earlier decisions of the MS TC, the QualityOfServiceInfo element of MessageHeader is removed, and the "idempotent" attribute is "promoted", so to speak, to the MessageHeader element. This text assumes that the CPA definition adopts our suggestion about the use of the "perMethod" value. If the CPA does not adopt this suggestion, the rules at the end of 7.4.1 must be changed accordingly. 3.1. idempotent attribute Valid values for idempotent are: true - the To Party MSH MAY assume that the message has idempotent semantics false - the To Party MSH MUST NOT assume that the message has idempotent semantics MWS: This definition sounds like the idempotent attribute is completely divorced from the reliable messaging protocol and applies equally well to bestEffort. Is that what is intended? The definition of "idempotent", and the interaction of this attribute with the "idempotent" element from the CPA, are described in section 7.4.1. 7.4.1 idempotent A message is said to be "idempotent" if processing the message more than once has the same effect as processing the message once. If the value of the "idempotent" parameter for a message is "true", the To Party MSH MAY safely assume that the message has idempotent semantics. If a duplicate idempotent message is received, i.e. if the same idempotent message is received more than once, the To Party MSH MAY deliver the message to the application more than once. (However, the To Party MSH is free to perform duplicate elimination even knowing that the message has idempotent semantics. This might be wise if the cost of re-processing the message exceeds the cost of duplicate elimination.) MWS: I agree with this definition of idempotent. As noted above, I am concerned about how it relates to reliable messaging and about the amount of redefinition of reliable messaging taking place in a maintenance release. If the value of the "idempotent" parameter is "false", the To Party MSH MUST assume that the message might not be idempotent. If a duplicate non-idempotent message is received, the To Party MSH MUST not deliver the message to the application more than once. That is, the To Party MSH must eliminate duplicates. The value of the "idempotent" parameter is controlled by the "idempotent" element of the CPA together with the "idempotent" attribute of the MessageHeader, as follows: -- If the value of the "idempotent" element of the CPA is "true" or "false": then the value of the "idempotent" parameter is "true" or "false" respectively. Furthermore, if the "idempotent" element is present in the MessageHeader, it must agree with the parameter value, or else the To party MSH reports an error with errorCode set to Inconsistent and severity set to Error. -- If the value of the "idempotent" element of the CPA is "perMessage": If the "idempotent" attribute of the MessageHeader is "true", the idempotent parameter is "true", otherwise the idempotent parameter is "false". ---------------------------------------------------------------- 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