RE: message routing

[Martin W Sachs <mwsachs@us.ibm.com>]

However we decide to generalize routing to the application, it is a version
2 matter, not a version 1.1 matter.  We will have to give a lot of thought
to use cases and to getting the specification correct.

REgards,
Marty

*************************************************************************************

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
*************************************************************************************



"Burdett, David" <david.burdett@commerceone.com> on 07/27/2001 07:44:32 PM

To:   "'Arvola Chan'" <arvola@tibco.com>, christopher ferris
      <chris.ferris@east.sun.com>, Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-cppa@lists.oasis-open.org, ebXML Msg
      <ebxml-msg@lists.oasis-open.org>
Subject:  RE: message routing




Arvola

Mapping the ebXML headers to headers of other popular  protocols was one of
the ideas we had for 1.0 for which we ran out of time. On  the other hand,
the inclusion of an optional general "Business Process Id"  as a URI to
hold a reference to the business process of which a message is part  sounds
an obviously good idea as it will be generally applicable to many uses of
ebXML Messaging. Do you agree?

The  question is should it be included in version 1.1 or version 2.0 of
ebXML  ...

David
-----Original Message-----
From: Arvola Chan  [mailto:arvola@tibco.com]
Sent: Thursday, July 26, 2001 9:41  AM
To: christopher ferris; Martin W Sachs
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.

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;-)
>