[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Re: [ebxml-dev] MSH 1.0 vs 2.0?
The appended correspondence is part of a discussion on the dev list about
interoperability (or lack thereof) between MSH v1 and v2. It suggests that
the CPA indicate which MSH version each party is using in order to
facilitate ad-hoc solutions to interoperability based on a party installing
both versions of the MSH. Presumably such a version indicator would be
part of the ebXML binding information.
While it has not been submitted as a formal comment, we might wish to
consider it now or post-V2.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
----- Forwarded by Martin W Sachs/Watson/IBM on 05/16/2002 06:22 PM -----
Andrzej Jan
Taramina To: Rudi Wirth <wirth@exln.com>
<andrzej@chaeron. cc: ebxml-dev@lists.ebxml.org
com> Subject: Re: [ebxml-dev] MSH 1.0 vs 2.0?
05/16/2002 06:05
PM
Please respond to
andrzej
Rudi:
> In our particular case, it would be the combination of the "adapter"
> name and the CPA location (by partyid). In other words, you'd configure
> two named ebXML adapters (ie MSH) as ie "ebxml104" and "ebxml" (2.0),
> both with the appropriate .jar, and then the respective CPA per
> participant/party. Otherwise, if you'd get the MSH version number from
> the CPA, you'd have to write conditonal ebXML java code if you keyed the
> adapter with just "ebxml". Hmm .. I guess conditional code works fine
> for minor version changes, ie 2.0-2.01, in which case the header would
> contain the ebMS string.
The problem I see with this is that it is a vendor specfic
solution....which seems a bit
out of place in an ebXML implementation that is supposedly standards based.
Inbound messages should not be a big deal, since the ebXML Message Header
provides a version attribute (1.0 or 2.0 right now) that an MSH
implementation (either
custom coded for part of a vendor solution) could use to determine how to
parse the
incoming message. Alternatively, it would be fairly easy to specify
different endpoint
URLs in the CPA that is in place with a specific trading partner, and these
URLs
would correspond to the MSH spec level supported by the particular
endpoint. I
expect that vendors of commerical MSH software will handle this scenario as
a
matter of course.
The more problematic part is sending of outgoing messages, since you need
to
figure out what version level your partner expects before sending the
message out
(unless you get lucky and they support both versions as noted above).
I would have thought that this would be something that should have been
also
specified in the CPA (and CPP's as well), but cannot find anything in the
CPPA 1.9
spec that would allow this. Either I have missed something obvious.....or
the CPPA
spec is lacking in this regard and needs to be extended to handle this
scenario. The
alternative is to rely on vendor/proprietary solutions for outbound
messages, which is
not a very attractive proposition!
...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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC