[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-dev] RNIF vs ebXML
So, here is my (possibly stupid) marketing question for the group.
Is there another version of RNIF planned; and if so, is the intention to migrate the Rosettanet framework to the ebXML architecture ?
From: Andrzej Jan Taramina [mailto:email@example.com]
Sent: Thursday, May 16, 2002 5:56 PM
Subject: (Fwd) [ebxml-dev] MSH 1.0 vs 2.0?
I'm forwarding this, since Rudi seems to be having trouble posting to the list.
------- Forwarded message follows -------
Date sent: Thu, 16 May 2002 16:10:54 -0400
From: Rudi Wirth <firstname.lastname@example.org>
Organization: eXcelon Corp.
Copies to: email@example.com
Subject: Re: [ebxml-dev] MSH 1.0 vs 2.0?
Andrzej Jan Taramina wrote:
> Could use a bit of help on some MSH version questions:
> 1) What is the difference between MSH 1.0 and 2.0 versions?
> 2) Is it possible to have two trading partners, at different MSH levels (1.0
> and 2.0) interoperate? Any issues attached to that?
> 3) Is it possible to run a 2.0-level MSH in a 1.0 compatibility mode? What do
> you lose if you do that?
> Thanks for your help in answering these....
> Chaeron Corporation
below's a good summary from David Fischer albeit it's now two months
old, and there were some tiny changes from 1.09 to 2.0.
We do have one customer that went through the exercise of getting a 1.04
MSH to interoperate with 2.0; the scenario was that their supply chain
(spokes) were using 1.04 and they tried to upgrade their hub to 2.0. I
don't have further details other than, obviously, they took our MSH
source code and "tweaked it to deal with the differences" on the hub.
However, I would've prefered a different scenario on the hub: in our
BPM, add both the 1.04 and 2.0 MSH adapters, and set up the Partners in
the Directory for either 1.04 or 2.0 communication. Since the
communication is handled in the ebXML gateway, you encapsulate the
messaging details from the BSI which then just deals with the payload.
On the outbound side back to the Partner, there's a late-binding
approach where we lookup the participant at runtime, on behalf of an
"activity" in the process flow that prepresents a web-service
invocation, to figure out what the communication is supposed to be, ie
ebMS 1.04 or 2.0 in our case.
I am suggesting this since you obivously can't get ebMS 1.0x and 2.0
interoperate in a production environment. But, what you can do, and
what you need to do in order to support partners that use different
messaging specs (not just ebMS 1,x 2.0, 3.0, etc, but also ie RNIF 1.1),
is to have a framework in place in your BPM to deal with these variants
of transports. That way, 1.04 partners talk 1.04, and 2.0 partners talk
2.0. The standard/spec defines the rules of communication between 2
parties; it's the BPM/communication framework behind the BSI that deals
with the variants.
Subject: RE: [ebxml-dev] ebXML Message Polling Mechanism
Date: Fri, 01 Mar 2002 14:36:46 -0600
From: David Fischer <firstname.lastname@example.org>
To: Anders TholÚn <email@example.com>
CC: "Ebxml-Dev (E-mail)" <firstname.lastname@example.org>
When we started the first UCC sponsored ebXML-MS Interoperability test,
already significantly taking shape (although at the time it was called
we decided to conform to the new spec. Consequently, we never ran any
The main changes in ebXML-MS from v1.0 to v2.0:
Via - Gone
TraceHeaderList - Gone
DeliveryReceipt - Gone
MessageHeader/QualityOfServiceInfo - Gone
deliverySemantics - Gone
messageOrderSemantics - Gone
deliveryReceiptRequested - Gone
MessageOrder - New top level element containing the
SequenceNumber child element
MessageHeader - Added DuplicateElimination child element
to replace deliverySemantics attribute
SyncReply - Changed to top level element
AckRequested - Changed from Attribute to top level element
Added Actor (nextMSH or ToPartyMSH) attribute
Acknowledgment - Added Actor (nextMSH or ToPartyMSH) attribute
Added RefToMessageId element
MessageHeader/PartyId - Added Role child element
Use of a CPA is now REQUIRED
We also did some rather major reorganizing of the spec into Core
Additional Features (which are all OPTIONAL). As you can see, these
make v2.0 not backward compatible.
I don't claim this is a definitive list (I am not aware that anyone has
yet) but it covers the salient points.
------- End of forwarded message -------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
Powered by eList eXpress LLC