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


Dan,
  See .. I really dont need everything from the ebXML stack. A shrink
wrapped solution for ebBPSS would be enough for me. 

+ Dipan

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Thursday, December 06, 2001 1:01 PM
To: Anarkat, Dipan
Cc: paechoi@earthlink.net; mwsachs@us.ibm.com; stefano.pogliani@sun.com;
ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] ebXML specifications interdendancies


   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.


[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