RosettaNet Message Header to ebXML Message Header Mapping

Attached please find a proposed mapping of RosettaNet Implementation
Framework (RNIF) 2.0 message header elements to ebXML message header
elements that Pete Wenzel, Brad Lund, Prasad Yendluri and I have put
together. This currently makes direct use of the SOAP-ENV:Header
extensibility feature to add RosettaNet namespace qualified elements, in
order to make it easy for solution providers to simultaneously support RNIF
2.0 and RNIF 3.0. (RNIF 3.0 is expected to be layered on top of the ebXML
Messaging Service.)

The purpose of this post is to solicit feedback on the naturaless of the
mapping, and to stimulate discussions on the completeness of the ebXML SOAP
Extension Elements schema. For example, should this mapping directly make
use of SOAP-ENV:Header extensions? Should the ebXML MessageHeader itself
allow for namespace qualified elements? Should additional elements be
provided in the ebXML header to avoid the need to encode multiple RNIF
header elements into a single ebXML header element?

For readers who are not familiar with the RNIF 2.0 header structures, I am
also attaching RosettaNet message guidelines for the RNIF DeliveryHeader adn
RNIF ServiceHeader. Further information on RNIF 2.0 can be found at:
http://www.rosettanet.org/rosettanet/Rooms/DisplayPages/LayoutInitial?Container=com.webridge.entity.Entity%5BOID%5BAE9C86B8022CD411841F00C04F689339%5D%5
D

-Arvola
  -----Original Message-----
  From: Arvola Chan <>
  To: Burdett David <>; christopher ferris
<>; Martin W Sachs <>
  Cc:  <>;
ebXML Msg <>
  Date: Friday, July 27, 2001 5:31 PM
  Subject: Re: message routing


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