Re: message routing

[Arvola Chan <arvola@tibco.com>]

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)

----- Original Message -----

From: "christopher ferris" <chris.ferris@east.sun.com>

To: "Martin W Sachs" <mwsachs@us.ibm.com>

Cc: <ebxml-cppa@lists.oasis-open.org>

Sent: Thursday, July 26, 2001 5:15 AM

Subject: Re: message routing

> Marty (or possibly more correctly Arvola),
> 
> Please 
see below.
> 
> Cheers,
> 
> Chris
> 
> 
Martin W Sachs wrote:
> <snip/>
> > 
> > I agree 
that it deserves attention, the larger question in my mind is what
> > 
manner of attention?
> > 
> > MWS:  The specific goal 
should be to satisfy the RosettaNet needs.  If we
> > can come up 
with a generalization that will accomplish a larger set of
> > needs, 
so much the better. For example, perhaps some routing URI that
> > 
contains
> > terms for all the routing levels
> > would be the 
way to go.  The critical point is that each of those levels
> > 
must
> > be visible in the BPSS instance document so that the BPSS 
instance document
> > continues to express the routing agreement that 
enables each party to send
> > a message with the routing information 
needed at the destination.  For
> > RosettaNet, it means that the 
BPSS instance document must include
> > surrogates
> > for all 
the levels that Arvola needs.
> > 
> <snip/>
> 
> I would agree that we should be striving to satisfy RosettaNet's 
needs,
> but IMHO, not to the exclusion of all others.
> 
> I 
take it that these needs are not satisfied with what is currently 
> 
available? I would like to understand the issues more thoroughly. 
> 
> First off, what is the issue with regards to routing that cannot 
be
> adequately expressed with CPAId, ConversationId, Service, 
Action
> AND state? If it is Role, which is absent from the Message, 
then
> this can be easily derived. Admittedly, it gets a little 
complicated
> when both parties can act in either role and this is 
expressed in 
> the same CPA, but it is still possible if you are willing 
to assume
> that the first message of a new conversation is always 
what
> it appears to be (the first message of a new conversation) as 
opposed to
> a message with the wrong service/action and 
conversationId.
> 
> In any event, you can derive role by working 
out which role in the CPA
> has service/action as its first message in the 
choreography. From
> there on, it is merely state information about the 
conversation.
> 
> I suppose that we could add it to the message as 
long as the MS TC 
> agreed. It seems overly redundant to me to be passing 
this around
> as the information IS in the CPA. Of course, if you're 
flying
> without a net, er... CPA, then all bets are off;-)
>