Arvola,
I completely agree with your last point. Using RosettaNet as an initial
use case, we must come up with a solution that will meet all the industry
standards that we are aware of and will be extensible to new applications.
I believe that the CPP-CPA will be affected along with the messag header.
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
*************************************************************************************
"Arvola Chan" <arvola@tibco.com> on 07/26/2001 12:40:45 PM
To: "christopher ferris" <chris.ferris@east.sun.com>, Martin W
Sachs/Watson/IBM@IBMUS
cc: <ebxml-cppa@lists.oasis-open.org>, "ebXML Msg"
<ebxml-msg@lists.oasis-open.org>
Subject: Re: message routing
Chris and Marty:
The RosettaNet message header currently carries a lot of redundant
information that can potentially be derived from the local software
configuration (i.e., the implicit bilateral trading partner agreement that
has been configured into the software). For example, David Fischer earlier
asked if there should be a place in the ebXML message header to carry the
PIP process identifier (e.g., PIP 3A4 Request Purchase Order). I believe
RosettaNet PIP actions have unique GlobalBusinessActionCodes, so if we use
the Action element to carry a GlobalBusinessActionCode, it should be
possible to do a table lookup using the Action element to determine the
RosettaNet PIP process identifier. Even if my uniqueness assumption turns
out to be false, it is still possible to encode the PIP process identifier
information into the Action element (perhaps using it as a prefix).
To ease solution providers' migration from the existing RosettaNet
Implementation Framework to a future version that takes advantage of the
ebXML messaging infrastructure, it will be highly desirable if all
existing RosettaNet message header elements can be mapped to equivalent
ebXML header elements, or carried as namespace specific extension elements,
rather than requiring convoluted lookups.
Appendix A (ebXML SOAP Extension Elements Schema) in the messaging service
spec shows that the MessageHeader can take wildcard attributes. It may be
useful to also allow an arbitrary number of namespace specific wildcard
elements to be included. Similarly, the MessageData element currently
carries a RefToMessageId element that can be used for correlation
purposes. In the RosettaNet case, an equivalent InReplyTo element carries
both a messageTrackingID as well as a GlobalBusinessActionCode. The latter
information while redundant helps the recipient to properly route the
response message.�Therefore, it�will be helpful if either the MessageData
element or the RefToMessageId can carry additional wildcard sub-elements.
Rather than tailoring the ebXML message header to meet RosettaNet's
requirements (and to the exclusion of all others), I would advocate�making
the ebXML message header sufficiently extensible so that it can meet the
needs of different industry specific standards.
Regards,
-Arvola
Arvola Chan (arvola@tibco.com)
TIBCO Software (on loan to RosettaNet)
+1-650-846-5046 (US-Pacific)