[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] ebXML specifications interdendancies
I do not think he is creating a problem. He is probably seeking for the right(from his perspectives) solution same as many others around world as I am expecting the growth of deamands as it gets mature and popular. And I am sure some vendors fussing about it and attempt to slow down the others because of some sort of their marketing strategies. Hey, the bottom line is that I am well be awaring of the benefits in collaborative solutions in our world. And so does others who putting extra amount of efforts in terms of the time and $s to produce the ebXML-based solution. And I am one if it. Let us see how and who can get the market acceptance whether they are Big boys or SMBs. Cheers, Pae > 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