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" <>
>
> 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".
----------------------------------------------------------------
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>
