ebxml-cppa message

Subject: Some Issues with the Reliable Messaging Specification in Version 1.0of ebMS
From: Martin W Sachs <[email protected]>
To: [email protected]
Date: Sun, 15 Jul 2001 22:05:11 -0400
The following just appeared on the ebXML-MSG list.  A few things mentioned
may indicate work needed on the CPP-CPA specification, probably working
jointly with the MSG team.

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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 07/15/2001
10:03 PM ---------------------------

Arvola Chan <[email protected]> on 07/15/2001 01:43:09 PM

To:   [email protected]
cc:
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 ([email protected])
TIBCO Software (on loan to RosettaNet)
+1-650-846-5046 (US-Pacific)