[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
No, you really don't need a CPA. While I can't image a system without some sort of TP database, there can easily be defaults which allow "bootstrap" situations. EDI does much the same thing with Open EDI -- Automatic Trading Partner Entry. When you receive a message which does not match any entry in the database, automatically create one with the transport values set to the incoming message values and anything which can be gleaned from the MessageHeader with all other values set to defaults. This is the only way large scale communications in a world-wide economy is going to work. It is simply not feasible to create manual database entries for hundreds of thousands of potential customers (like the case of Sears or L.L.Bean). This will be a must for small quantity/value, large volume organizations. In large value propositions, you will probably want a more structured approach. This is where CPA/CPP will excel. Regards, David Fischer Drummond Group. -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: Tuesday, July 17, 2001 8:27 AM To: Burdett, David Cc: Arvola Chan; ebxml-msg@lists.oasis-open.org Subject: RE: Some Issues with the Reliable Messaging Specification in Vers ion 1.0 of ebMS David, But if the CPA is not used, the two parties have to first get on the phone to negotiate what they have to agree on to be able to send that message without a CPA, and then they both have put that information into their systems and get it consistent and correct. There's no free lunch. If the negotiable information is simple, the CPA will also be simple. In some cases a third party may be able to dictate all of the variables. The RNIF seems to be one such case and I assume that CommerceOne is another. Relying on such third parties may only serve to divide the world into islands that can't easily interoperate. I have been discussing this with someone who is trying to implement a message service to work either way. That's not easy. In order for the message service spec to cover both cases, some of its statements are so broad or vague that they don't give sufficient guidance to the implementer. The CPPA team has an open work item to write an appendix for its spec showing how the elements in the message header are to be used with the CPA. However, that information really should be in the message service spec. Yes, the spec needs to be clarified. Clarification is needed not just to make it clear that the CPA is optional. All of the ambiguities resulting from the CPA needing to be optional have to be located and clarified in the form "this is what you do if you have a CPA and this is what you do if you don't have a CPA." 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 ******************************************************************************** ***** "Burdett, David" <david.burdett@commerceone.com> on 07/17/2001 01:24:00 AM To: Arvola Chan <arvola@tibco.com>, ebxml-msg@lists.oasis-open.org cc: Subject: RE: Some Issues with the Reliable Messaging Specification in Vers ion 1.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: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: 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 (arvola@tibco.com) TIBCO Software (on loan to RosettaNet) +1-650-846-5046 (US-Pacific) ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC