[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: message routing
Arvola, Please see below. Cheers, Chris > Arvola Chan wrote: > > 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. I probably wouldn't characterize the look ups as convoluted. > > 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. Is the messageTrackingId equivalent to the MessageId or is it something else entirely? Couldn't you simply add the InReplyTo header as a separate SOAP block, namespace qualified to the RosettaNet namespace? Either that, or it could simply be added as a namespace qualified extension to the MessageHeader element. I see no explicit need to have the MessageData element explicitly extensible. > > 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. I believe that it already is sufficiently extensible. Some would argue that it is too much so (although I am not one of them). > > 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;-) > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC