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: Some Issues with the Reliable Messaging Specification in Version 1.0of 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?
 
Thanks,
-Arvola
 
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