RE: [ebxml-dev] ebXML specifications interdendancies

["Anarkat, Dipan" <DAnarkat@uc-council.org>]

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:paechoi@earthlink.net]
Sent: Wednesday, December 05, 2001 12:18 PM
To: Dan Weinreb; Anarkat, Dipan
Cc: mwsachs@us.ibm.com; stefano.pogliani@sun.com;
ebxml-dev@lists.ebxml.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".