Dan Weireb wrote:
» 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".
well, IMHO it will be a good logical architecture to keep things
separate. If, at the end, a product presents a comprehensive
solution that supports ebXML from A to Z, it will be great from
a user perspective since they will have to interface with one
single thing.
But from the point of view of architecting such product, I can
clearly see the separation. And this because I do not see the things
"from the point of view of the MSH"; I see the issue from the point
of view of the agent which has to realize at runtime what the CPA
stipulates.
Obviously, this is an opinion only.
Best regards
/stefano
» -----Original Message-----
» From: Dan Weinreb [mailto:]
» Sent: 05 December 2001 17:52
» To:
» Cc: ; ; ;
»
» Subject: Re: [ebxml-dev] ebXML specifications interdendancies
»
»
» 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>
