Re: [ebxml-dev] ebXML specifications interdendancies

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Thu, 6 Dec 2001 12:52:32 -0500 
   From: "Anarkat, Dipan" <DAnarkat@uc-council.org>

   The "ebCPA handler" module I assume would address CPA negotiation. 

Oh, I see.  Yes, that would indeed really be a separate module.

If you then wanted to buy a CPA negotiator module from one vendor and
an MSH from another vendor, it might be that the only thing you need
for them to interoperate reasonably would be the CPA spec itself.
(You might need more if you wanted "smoother" integration,
e.g. something to automatically "pick up" the CPA produced by the
negotiator and put it where the MSH expects to find it, or something
like that.)

      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 ? 

I'm not sure I understand properly to what extent the ebMS protocol
considers itself to be extensible like this.  I have not seen much (in
fact, not any, I think) discussion of trying to run ebMS with
extensions that are not part of the ebMS standard.

							   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.

Since AS2 is already taking care of so many things for you, you will
probably find that a good portion of what the CPA deals with isn't
relevant.  BPSS, on the other hand, I would think would be no problem.
It seems to me that BPSS is pretty much layered on top of the MS and
CPA concepts, and could be used with an alternative pretty
transparently.