(Fwd) [ebxml-dev] MSH 1.0 vs 2.0?

[Andrzej Jan Taramina <andrzej@chaeron.com>]

I'm forwarding this, since Rudi seems to be having trouble posting to the list.

....A


------- Forwarded message follows -------
Date sent:      	Thu, 16 May 2002 16:10:54 -0400
From:           	Rudi Wirth <wirth@exln.com>
Organization:   	eXcelon Corp.
To:             	andrzej@chaeron.com
Copies to:      	ebxml-dev@lists.ebxml.org
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....
>
> ...Andrzej
>
> Chaeron Corporation
> http://www.chaeron.com

Hello Andrzej,

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.

Regards,
-Rudi

------

Subject: RE: [ebxml-dev] ebXML Message Polling Mechanism
   Date: Fri, 01 Mar 2002 14:36:46 -0600
   From: David Fischer <david@drummondgroup.com>
     To: Anders Tholén <anders_tholen@yahoo.com>
    CC: "Ebxml-Dev (E-mail)" <ebxml-dev@lists.ebxml.org>

When we started the first UCC sponsored ebXML-MS Interoperability test,
v2.0 was
already significantly taking shape (although at the time it was called
v1.1) so
we decided to conform to the new spec.  Consequently, we never ran any
tests on
v1.0.

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
Components and
Additional Features (which are all OPTIONAL).  As you can see, these
changes
make v2.0 not backward compatible.

I don't claim this is a definitive list (I am not aware that anyone has
made one
yet) but it covers the salient points.

Regards,

David Fischer
Drummond Group
ebXML-MS Editor

------- End of forwarded message -------
...Andrzej

Chaeron Corporation
http://www.chaeron.com