OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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

FRC B2B System

-----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
happen if the MSH software supplier only supports one version and validates
incoming message).  The preferred solution would be to "preparse" the
message to
check the version information....say using a  non- validating SAX parser
which would extract the incoming message MSH version info from the header
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

Outgoing Messages:

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

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

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
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
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.
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
always control which ebXML implementation your partners will select.  For
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.

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
Again quoting from a different email exchange:

> For future versions, [OASIS] intends for specs to be backward compatible.
> 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
will be backward compatible, and it's been my experience, especially with
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,
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
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
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
attributes is vendor specific.

2) There is a definite vendor lag time in adoption and implementation of new
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
more likely that early adopters of ebXML MSH will run into 1.0 to 2.0

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
adopter customers migrate to those new versions, thus making the situation
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
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!


Chaeron Corporation

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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC