OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Some Issues with the Reliable Messaging Specification in Vers ion1.0 of ebMS

You have spotted one of the inconsistencies that, in my opinion, needs to be fixed. It arose because there were two different views on the relationship between the CPA spec and the ebMS spec. This really boiled down to whether the CPA was always required or optional. I will say now that I was always firmly in the latter camp and think that the CPA should be optional. The main reason for this was that if the CPA is required, then you cannot just send a message to someone, you have to negotiate the CPA first and how you do this has not been specified.
You are also right that there are issues around using the reliable messaging spec over multiple hops which need to be resolved.
However the spec does need to be clarified in my opinion to make it clear the the CPA is optional. Removal of this inconistency (and a few others) is one of the things that I will suggest at the ebMS meeting tomorrow and Wednesday.
Thanks for your comments.
PS Most specifications seem to go through some type of revision after they are published ... ;)
-----Original Message-----
From: Arvola Chan [mailto:arvola@tibco.com]
Sent: Sunday, July 15, 2001 10:43 AM
To: ebxml-msg@lists.oasis-open.org
Subject: Some Issues with the Reliable Messaging Specification in Version 1.0 of ebMS

Section 10.2 in the ebMS spec describes the reliable messaging parameters: deliverySemantics, mshTimeAccuracy, TimeToLive, reliableMessagingMethod, ackRequested, retries, retryInterval, persistDuration. Only deliverySemantics, TimeToLive, reliableMessagingMethod, ackRequested can be found in Appendix A (ebXML SOAP Extension Elements Schema); retries, retryInterval, and persistDuration can only be found in Appendix D of the ebCPP spec.
I find the statement on line 1695 "This parameter information can be specified in the CPA or in the MessageHeader (section 8.4.2)." imprecise in the following sense:
  1. mshTimeAccuracy is neither in the MessageHeader nor in the CPA.
  2. TimeToLive is not mentioned anywhere in the CPA. It is not clear how the sending MSH should pick a value for this parameter.
  3. The sub-sections describing retries, retryInterval, and persistDuration do not clearly indicate that these parameters are to be obtained from the CPA. Furthermore, their spellings do not match those in the CPA (case difference). It will be helpful to specify how elements in the MessageHeader can be used to look up these values from the CPA. The CPAId alone is not sufficient. The Service and Action elements will also have to be used to locate the relevant DocExchange, ebXMLBinding, and ReliableMessaging elements from the CPA.
It is not clear if the current Reliable Messaging specification works over multiple hops. Line 1774 prescribes that a TraceHeader be created in accordance with Section 8.5.2. The latter section however does not say anything about how to determine the next intermediary, in those cases where one or more intermediaries are to be involved. The descriptions on lines 1825 and 1829 on how to populate the From and To element in the Acknowledgement Message also do not clearly explain the circumstances under which sub-elements under the last TraceHeader in the incoming message are to be used.
I also find the following issues with Section 10.3.2 on Receiving Message Behavior:
  1. Line 1783 uses the URI http://www.ebxml.org/namespaces/messageService/MessageAcknowledgement. This is not consistent with the URI specified on line 1823: uri:www.ebxml.org/messageService.
  2. Steps 2.d)i) on line 1800 and 2.d)ii) on line 1802 are confusing. The phrase "and resend it" on line 1800 should be struck out. Otherwise, the message would be resent twice.
  3. Step 2.c) omits the crucial action of passing on the message which has been found not to be a duplicate to the application.
  4. Step 2.d)iii) is incomplete. The action to be taken when syncReply is set to True and the CPA indicates no application response is included is left unspecified. I believe in this case an Acknowledgement Message should be generated and returned synchronously.
Under Section 10.3.5 Duplicate Message Handling, I find the description of an "identical message" puzzling.  Why is it possible for a duplicate "identical" message to have an additional TraceHeader? Is the sending MSH required to append another TraceHeader when it resends a message because an Acknowledgement Message has not been received in time? Or is it required to update the Timestamp in the TraceHeader to reflect the time of retransmission?
Arvola Chan (arvola@tibco.com)
TIBCO Software (on loan to RosettaNet)
+1-650-846-5046 (US-Pacific)

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC