OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: message routing


Please see below.



> 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