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