MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
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)