[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