[ebxml-dev] More on MSH 1.0 vs. 2.0 migration/interop...

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

Been doing a lot of research into this area....figured I would pass on my findings and
observations so far.

There are two use cases that need to be addressed, regarding MSH 1.0 vs. 2.0
interoperability, namely,  incoming and outgoing messages.

Incoming Messages:

It would be undesireable for a partner to send a message and have it bounce with a
validation error because of a MSH version mismatch (which is what would typically
happen if the MSH software supplier only supports one version and validates the
incoming message).  The preferred solution would be to "preparse" the message to
check the version information....say using a  non- validating SAX parser routine
which would extract the incoming message MSH version info from the header and
then route to an appropriate "real" parser based on that version.  This is easily done
using the mandatory version attribute in the MSH Message Header.

Another way to handle this is to specify different endpoint URL's for 1.0 and 2.0 as a
quick workaround till the software supplier can properly parse the MSH ader version
info.


Outgoing Messages:

I have discovered that the CPPA spec does let you specify the MSH version already.
It is in the DeliveryChannel/DocExchange element. Here is a snippet from CPPA
1.09 :

<tp:DocExchange tp:docExchangeId="docExchangeB1">
<tp:ebXMLSenderBinding tp:version="2.0">
<tp:ReliableMessaging>
 .  .  .  .
</tp:ReliableMessaging>
.  . .
</tp:ebXMLSenderBinding>)

However CPPA 1.9 is not yet ratified.  The current 1.0 CPPA spec also provides for
this, but using a ebXMLBinding tag instead.

The preferred solution, in my mind, would be to use the CPA to specify the MSH
version level for the particular partner-collaboration. The MSH implementation would
check the CPA for which version of MSH the partners have agreed to use, and then
format the outgoing message using that level of spec. Clean.....standards-
based....non-proprietary.  Bit of futzing since the tag has changed from CPPA 1.0 to
1.9, but that is not a really big deal.


More general comments:

I am pushing the vendors that I am dealing with to adopt the above approach.  A
comment was made to me to the effect of:

> We discussed a bit about this during our 2.5 requirements and concluded at
> that time 1.0 support may not be a hot requirement. Given the fact that
> there were no 1.0 MSHs in production and that the authors themselves
> decided against backward compatibility in 2.0 (for both MS and CPPA).

I disagree with this viewpoint.  It seems that there will be such a requirement, at least
for implementations that fire up in the next year.  The reason is that you cannot
always control which ebXML implementation your partners will select.  For example,
in one pilot I am involved with, the intermediary/partner will likely want to use Vendor
A's implementation, which is only MSH 1.0 right now.....and likely won't go 2.0 till
mid-summer for beta....final in the fall sometime.  If Vendor B's ebXML
implementation is selected instead, that vendor won't have 2.0 in beta till
end of '02....final in early '03.  The issue is compounded since shortly after the first
pilot goes production (as early as this fall even), I'm sure my customer will will want
to add other partners....and they may be using different MSH versions. Oooops!

So you can see that we can easily run into this problem for the next year or so.  I
don't believe we will be alone in this.

1) This problem is compounded by a number of factors that need to be considered.
Again quoting from a different email exchange:

> For future versions, [OASIS] intends for specs to be backward compatible. How
> you specify which MS layer to use could be in the CPA but I doubt they
> would address this. I think instead it will addressed by the vendor.

The key word in the above is "intend".  OASIS cannot guarantee that future specs
will be backward compatible, and it's been my experience, especially with relatively
new technologies that have not had wide production implementation yet (like
ebXML), that the likelyhood of a major, incompatible change is fairly high.  I think it
would be a good strategy to build new MSH implementations with this in mind, and
plan to support incompatible MSH versions, but using the MSH Header and
ebXMLSenderBinding/ebXMLBinding version attributes as noted above.  Then the
software  vendor will guarantee that their customers will not have any problems,
regardless of what OASIS ends up doing to future specs.  The nice side benefit is
that they also end up solving the 1.0 to 2.0 interop issue at the same time as they
position themselves and your customers for future changes with minimal impact and
a clean migration path.

Handling this in a vendor proprietary manner (eg. not using the version attributes)
would be quite undesireable in my opinion, though of course how a vendor does their
internal implementation of the MSH parsing/routing/plugins based on these version
attributes is vendor specific.

2) There is a definite vendor lag time in adoption and implementation of new OASIS
specifications.  One vendor (alluded to above) will not have a MSH 2.0 beta out till
end of this year, and final release early '03, and that assumes that they make their
schedule (not something I take for granted).  This vendor lag time makes it even
more likely that early adopters of ebXML MSH will run into 1.0 to 2.0 interop
problems.

3) The vendor lag is compounded even more by customer adoption lag time.  Even if
vendors do get MSH 2.0 versions out the door...it will be even longer before early
adopter customers migrate to those new versions, thus making the situation even
more likely.

As a consequence of the above, I strongly urge ebXML software vendors to plan for
and start implementation of multiple MSH version support by using the MSH Header
version attribute to route incoming messages (and possible different endpoint URLs
as a short term workaround) and the CPPA ebXMLSenderBinding/ebXMLBinding
version attributes to determine how to format outgoing messages.

Thanks for listening!








...Andrzej

Chaeron Corporation
http://www.chaeron.com