David:
Pete Wenzel, Brad Lund, Prasad Yendluri and I have
previously made an attempt to map RosettaNet RNIF 2.0 message header elements to
the 0.99 version of the ebXML message header elements. I can try to update the
mapping to correspond to the 1.0 spec and share it with the team.
I am in favor of including an optional general
"Business Process Id" element to the 1.1 version of ebXML Messaging. I agree
that it is generally applicable and I don't think it should lead to
any backward compatibility problem.
Regards,
-Arvola
----- Original Message -----
From:
Burdett, David
To: 'Arvola Chan' ; christopher ferris ; Martin W Sachs
Cc:
; ebXML Msg
Sent: Friday, July 27, 2001 4:44 PM
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:]
Sent: Thursday, July 26, 2001 9:41
AM
To: christopher ferris; Martin W Sachs
Cc: ;
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 ()
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;-)
>
