[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-dev] ebXML specifications interdendancies
Dan The "ebCPA handler" module I assume would address CPA negotiation. If ebXML does not define a CPA neogtiation process , I would definitely want to go to a vendor who provides CPA neogtiation capabilites using message exchanges. I believe that ebMS can be customised/extended (using SOAP extensions) to provide CPA negotiation capabilities (something similiar to Reliable Messaging !? ). Well my whole confusion is, when ebMS can be customised/extended to have additional messaging features (using SOAP extensions), how do I use it without getting locked down into a propreitory messaging solution from vendor , until ebXML addresses it in the standard ? Anywayz, I dont know if my argument makes any sense at all. Besides always believed that a modular architecture with Service Provider Interfaces (SPI) for handlers and standard API's ( like in JAVA ) created the best market solutions. The ebXML groups have definitely done their work , but I think the implementations should also be made more configurable to maximize usability. Again these are just passing thoughts ! Let me tell you where my thoughts/concerns come from. I am trying to understand how our existing users (EAN.UCC members) most of which use EDI-INT AS2 as the TR&P protocol can use our standards along with ebBPSS ( and maybe ebCPA ) without having to use ebMS and having to break existing infrastructure. The reasons being : # EDI-INT AS2 infrastructure already set-up and being used as the TR&P protocol # Point-to-Point messaging satisfies peer-to-peer business exchanges between trading partners, multi-hop not really required # Reliable-mesaging , security , error-handling, QoS addressed by AS2 is sufficient # Huge investments already around AS2, not practical to move to evolving ebXML specs / technologies and products # Something like an BPSS engine maybe useful as an extension to existing implementations. I dont know if there are any vendors who have thought about this, but this MAY actually be practical user requirement. Again this is just a passing thought :) ! Dipan Anarkat Uniform Code Council, Inc. Tel: (609)-620-4509 http://www.uc-council.org/ -----Original Message----- From: Pae Choi [mailto:email@example.com] Sent: Wednesday, December 05, 2001 12:18 PM To: Dan Weinreb; Anarkat, Dipan Cc: firstname.lastname@example.org; email@example.com; firstname.lastname@example.org 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