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


I completely agree with your last point.  Using RosettaNet as an initial
use case, we must come up with a solution that will meet all the industry
standards that we are aware of and will be extensible to new applications.
I believe that the CPP-CPA will be affected along with the messag header.



Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com

"Arvola Chan" <arvola@tibco.com> on 07/26/2001 12:40:45 PM

To:   "christopher ferris" <chris.ferris@east.sun.com>, Martin W
cc:   <ebxml-cppa@lists.oasis-open.org>, "ebXML Msg"
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.


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
> >  manner of attention?
> >
> > MWS:  The specific goal  should be to satisfy the RosettaNet needs.  If
> > 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
> >  must
> > be visible in the BPSS instance document so that the BPSS  instance
> > continues to express the routing agreement that  enables each party to
> > 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