[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] ebXML specifications interdendancies
Date: Wed, 05 Dec 2001 10:20:32 -0500 From: "Anarkat, Dipan" <DAnarkat@uc-council.org> Pae Choi, I see a vendor lockdown over here. If my company and the trading partners are using ebXML for everything then I need to find a vendor whose ebXML B2B app supports all the modules on the ebXML stack . Since there are no standard interfaces defined b/w an : #ebMS handler and an ebCPA handler #ebCPA handler and an ebCPP handler #ebCPP handler and an ebRR #ebCPA handler and an ebBPSS handler #etc. how can I probably get a best-of-the breed solution from the market ? Maybe JAVA may help here to define standard interfaces for communcation b/w different ebXML handlers. Any comments ? I think you're creating a problem rather than solving an existing one. Just because the CPP/CPA and the MS are being defined by different groups of people does not imply that ebXML implementations will consist of independent software modules to handle one and the other, or that they even ought to. For example, right now, it's usually not easy for you to pick an IP (Internet Protocol) implementation from one vendor and a TCP implementation from another vendor and plug the in together. It's just not important to be able to do that. In the case of ebXML, it's even less sensible to suppose that you'd do that, because it's not a case of two protocols layered on each other. CPA/CPP isn't a protocol layer. From the point of view of an MSH implementation, the CPA is a data structure used at runtime. There just isn't any reason for their to be a separate, seperable beast called an "ebCPA handler".
Powered by eList eXpress LLC