[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-cppa] reliable messaging comments
Marty, Yes, I was referring to your 8.4.40 comment below. So we can add a clarification to the final spec. Tony, Can we add a pointer to the Messaging table 6.6 in connection with Marty's observation and that will help provide useful continuity? I am uncertain where refs would be most useful, but probably under the DocExchange elements and other information items pertaining to Acks and Retries and/or duplicate elimination. Dale -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Monday, April 15, 2002 4:04 PM To: Dale Moberg Cc: Arvola Chan; ebxml-cppa@lists.oasis-open.org Subject: RE: [ebxml-cppa] reliable messaging comments Dale, I assume you are referring to my comment on 8.4.40. You are probably right. In that case, a reference to table 6.6 in the ebMS specification is in order. Regards, <artu ************************************************************************ ************* 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 ************************************************************************ ************* "Dale Moberg" <dmoberg@cycloneco To: Martin W Sachs/Watson/IBM@IBMUS, "Arvola Chan" mmerce.com> <arvola@tibco.com> cc: <ebxml-cppa@lists.oasis-open.org> 04/15/2002 06:21 Subject: RE: [ebxml-cppa] reliable messaging comments PM Marty, The delivery semantics values discussed in the ebMS specification (table 6.6) are largely supplanted by combinations of specific factors involving ackRequested and duplicateElimination. The 4 values do not translate uniquely into the 8 permutations. The CPPA instead deals with the factors leading to the combinations directly. If the delivery semantics needed to be characterized, they could be derived from table 6.6 in accordance with the fundamental parameters in the configuration parameter aggregate. Do we really want to have those values in the CPA for the 2.0 specification? We largely replaced them because Messaging 2 focused on whether Acks were requested (and from whom) and whether the final destination was doing duplicate elimination... Dale Moberg -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Monday, April 15, 2002 2:08 PM To: Arvola Chan Cc: ebxml-cppa@lists.oasis-open.org Subject: RE: [ebxml-cppa] reliable messaging comments Arvola, Thanks for the clarification. Tony, please add cross references in the persistDuration section to the duplicate-elimination and message order semantics sections to enable someone to find the rules that govern persistDuration. In addition, I believe that my comment to 8.4.40 below is still operative. 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 ************************************************************************ ************* Arvola Chan <arvola@tibco.com To: Martin W Sachs/Watson/IBM@IBMUS, ebxml-cppa@lists.oasis-open.org > cc: Subject: RE: [ebxml-cppa] reliable messaging comments 04/15/2002 02:39 PM Marty: The MessagingCharacteristics under DeliveryChannel element contains the following attributes: - syncReplyMode - ackRequested - ackSignatureRequested - duplicateElimination - actor These attributes summarize the messaging behavior associated with the delivery channel. Auxiliary information is found under the DocExchange element. The ReliableMessaging element provides retry, retry interval, and messaging ordering semantics, if ackRequested is set to "always" or "perMessage". If ackRequested is set to "none", then information provided by the ReliableMessaging element is essentially ignored at run time. The PersistDuration element was originally a sub-element of ReliableMessaging. The decision to make it a sibling of ReliableMessaging was made during the January CPP/A F2F meeting. The rationale was that in ebMS 2.0, duplicate elimination can be controlled independent of the use of the AckRequested element. The PersistDuration is needed to deterimine how long a message should be kept in persistent storage to facilitate duplicate elimination. If the duplicateElimination attribute is set to "perMessage" or "always", the PersistDuration element must be present. Similarly, if the ackRequested element is set to "perMessage" or "always", the ReliableMessaging element must be present. These constraints are already stated in the sections on the ackRequested attribute and on the duplicateElimination attribute. The CPA composition tool should flag an error if any of these constraints is violated. -Arvola -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Saturday, April 13, 2002 9:29 PM To: ebxml-cppa@lists.oasis-open.org Subject: [ebxml-cppa] reliable messaging comments Following are significant technical comments on reliable messaging in V1.11 that should be discussed as soon as possible Section 8.4.40, ReliableMessaging element We need to state what delivery semantics are implied by the presence of the ReliableMessaging element. Is it onceAndOnlyOnce or does it depend on the states of its child elements and the PersistDuration element? Section 8.4.41, PersistDuration element Since the PersistDuration has cardinality 0 or 1, we need tighter rules on its use besides the rule that it must appear if MessageOrder is "guaranteed". PersistDuration applies to, and only to, reliable messaging. Therefore, it should be a child element of the ReliableMessaging element. We need to state what happens to duplicate elimination if the PersistDuration element is omitted. Possibilities are: Duplicate elimination takes place but the value of PersistDuration is a local matter. There is no duplicate elimination and the delivery semantics become atLeastOnce, which is not really reliable messaging. The short term answer to the above has to be consistent with ebMS 2.0. 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 ************************************************************************ **** ********* ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- 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