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

Arvola

 

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.

 

David

PS 
Most specifications seem to go through some type of revision after they are 
published ... ;)

  
-----Original Message-----
From: Arvola Chan 
  [mailto:]
Sent: Sunday, July 15, 2001 10:43 
  AM
To: 
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: 

  
    
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)