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

[Belford Neil <Neil.Belford@vencorp.vic.gov.au>]

Thanks for that Andrzej - The South East of Australia is half way through a
change to full Retail Contestability in gas and the participants and the hub
are using v1.0 MSH's. I have been wondering about what kind of evolution
options we are going to have available to us. I can see the scenario you
have outlined working for us.


Neil Belford

Architect, 
FRC B2B System
VENCorp 
http://www.vencorp.com.au
 


-----Original Message-----
From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
Sent: Friday, May 17, 2002 10:52 PM
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] More on MSH 1.0 vs. 2.0 migration/interop...


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



----------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebxml.org/ob/adm.pl>


******************************************************************
This e-mail is confidential and for the sole use of the intended 
recipient(s).  If you are not the intended recipient, you are not 
authorised to disclose, use, distribute or in any other way make 
use of the information contained in it, and such activities are 
prohibited.  If you have received this e-mail in error, please 
notify the sender by reply e-mail, delete the document and destroy 
all copies of the original message.
******************************************************************