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


Mike,

   Architecting open and flexible ebXML B2B messaging solutions should be
left to forums like JCP, who are and will define standard API and SPI's . 
Besides you are right, we should learn to walk first before we try to run.
   
Regards

Dipan Anarkat
Uniform Code Council, Inc.
Tel: (609)-620-4509
http://www.uc-council.org/



-----Original Message-----
From: Mike Rawlins [mailto:mike@rawlinsecconsulting.com]
Sent: Wednesday, December 05, 2001 10:39 AM
To: Anarkat, Dipan
Cc: 'Martin W Sachs'; Pae Choi; Stefano POGLIANI;
ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] ebXML specifications interdendancies


At Wednesday, 05 December 2001, "Anarkat, Dipan" <DAnarkat@uc-council.
org> wrote:

>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 ?

<flame>
Since you asked for comments:  Oh boy, now we have yet *another* 
set of stuff to standardize!  If this approach is taken we really 
are just moving complexity around, and not eliminating it.  I predict 
that if this approach is taken, somewhere up at the next level in 
the stack we'll find something else to standardize. ;^)
</flame>

At this point in time comprehensive packages from a single vendors 
make much more sense that trying to fully modularize (a la "plug 
and play") the architecture.  However, I do note that some of the 
interfaces you list above might consist of passing only a file or 
a few parameters (such as ebCPA handler and ebBPSS handler), and 
others may not necessarily have any interfaces (such as between ebCPA 
handler and ebCPP handler).  So, a certain degree of modularity may 
be achievable without too much effort.
-------------------------------------

Mike Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com




=end of email===



[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