OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC