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:]
Sent: Wednesday, December 05, 2001 12:18 PM
To: Dan Weinreb; Anarkat, Dipan
Cc: ; ;
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" <>
>
> 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>
