Chris:
.
My responses are inline are bracketed by
<arvola> and </arvola>.
Regards,
-Arvola
----- Original Message -----
From: "christopher ferris" <>
To: "Arvola Chan" <>
Cc: "Martin W Sachs" <>; <>;
"ebXML Msg" <>
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 ()
> TIBCO Software (on loan to RosettaNet)
>
+1-650-846-5046 (US-Pacific)
> ----- Original Message -----
> From:
"christopher ferris" <>
> To: "Martin W Sachs" <>
> Cc: <>
> 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;-)
>
>
