[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: message routing
Arvola, Hmmm. you're correct. I had forgotten that we removed the any from MessageHeader since the SOAP:Header could already carry namespace qualified extensions. Is there a problem with having the InReplyTo included as a separate SOAP header block? Cheers, Chris > Arvola Chan wrote: > > Chris: > . > My responses are inline are bracketed by <arvola> and </arvola>. > > Regards, > -Arvola > > ----- Original Message ----- > From: "christopher ferris" <chris.ferris@east.sun.com> > To: "Arvola Chan" <arvola@tibco.com> > Cc: "Martin W Sachs" <mwsachs@us.ibm.com>; <ebxml-cppa@lists.oasis-open.org>; "ebXML Msg" > <ebxml-msg@lists.oasis-open.org> > Sent: Thursday, July 26, 2001 10:33 AM > 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. > > <arvola> > Convoluted may have been an inappropriate characterization. Still it is going to impose additional > implementation requiremenets that may slow adoption. > </arvola> > > > > > 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. > > <arvola> > Yes, the messageTrackingId is equivalent to the MessageId. It is possible to add information from > the InReplyTo header as a separate SOAP block. It is also possible to add as a namespace qualified > extension to the MessageHeader element provided we allow namespace qualified extension elements in > the MessageHeader. I was thinking that keeping information from the InReplyTo element in close > proximity to the RefToMessageId would make logical sense. > </arvola> > > > > > 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