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: 

  
mshTimeAccuracy is neither in the MessageHeader 
  nor in the CPA.

  
TimeToLive is not mentioned anywhere in the CPA. 
  It is not clear how the sending MSH should pick a value for this 
  parameter.

  
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:

  
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.

  
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.

  
Step 2.c) omits the crucial action of passing on 
  the message which has been found not to be a duplicate to the 
  application.

  
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 ()

TIBCO Software (on loan to RosettaNet)

+1-650-846-5046 (US-Pacific)