Re: [ebxml-dev] ebXML CPA/CPP Estimate

[Farrukh Najmi <Farrukh.Najmi@Sun.COM>]

Mike,

Before I too bow out of this umm discussion I wanted to express my support
for the CPP/A as a customer of this good work. I liked it when it was TPAML
and I like it even better now.

For what its worth, it is planned for the ebXML Registry TC to adopt and
define a normative template CPP for the registry client and the registry
service. We deferred this work to Version 3 to allow the CPP/A
specifications to achieve stability. With Version 2 nearly out the door as
we speak and with CPP/A reaching stability, the OASIS ebXML Registry TC
members will begin actively engaging and coordinating with our colleagues in

the OASIS ebXML CPP/A TC.

As customers of the output of the CPP/A team we view this work to be solving

some significant problems such as determining the compatible intersection of

capabilities between the client and the registry. Until we use the CPP/A we
have to assume a certain uniformity of capabilities among clients and
registries.

As an implementor of the ebXML stack and as a Java developer I am excited
about the new Java API for CPP/A:

 http://www.jcp.org/jsr/detail/157.jsp

This will guarantee a high quality reference implementation (RI) of the
CPP/A spec as well as a conformance test suite.
This CPP/A RI would likely be used in the RI for the OASIS ebXML Registry
being developed in Open Source at:

http://sourceforge.net/projects/ebxmlrr

We may chose to disagree Mike, but I am willing to bet the farm that this
work will not merely survive in the adoption game but it will be a smashing
hit. And when it is, I am sure people from all kinds of cracks will pop up
reminding us that they were part and knew it would be a hit all along.

--
Regards,
Farrukh

Mike Rawlins wrote:

> One more note on this before I excuse myself from this discussion for
> awhile:
>
> I seem to have hit a few nerves with my estimate of the ebXML CPA/CPP
> only having a .2 probability of achieving critical mass (at least as I
> have defined it).  These discussions have caused me to carefully
> reconsider this assessment, though I haven't changed it yet.  What I
> would like to offer is a more specific rationale for a relatively low
> estimate, whatever the value is.  Again, I will fall back to current EDI
> practice, since that's the best we have to work with.  My experience has
> been that configuring an EDI management system for a new trading partner
> in most cases takes only 5% to 10% of the total effort of bringing a new
> partner into production.  Your mileage may vary, but that is less than
> an hour for me, including e-mails, phone calls, etc.  The remaining 90%
> + of the effort is elsewhere - developing the transformations, testing,
> etc.  Given that we can at best achieve a 10% reduction in effort by
> automating most of the trading partner configuration, is there
> sufficient ROI for vendors to implement and end users to use?
>
> A few caveats to this analogy:  Exchanging information securely over the
> public Internet using the ebXML MHS requires more configuration options
> to be specified than is the case with a typical EDI system.  So, in the
> ebXML model the configuration may represent a larger percentage of the
> effort, and therefore there may be a greater savings from using the
> CPA/CPP.  In addition, if the whole ebXML vision is ever fully realized
> (which I'm *not* taking for granted any time in the near future) the
> remaining efforts (that take 90% of the effort in the EDI model) may be
> so reduced that manual configuration could take much more than 10% of
> the total effort.  This provides additional justification for the
> CPA/CPP.  Open-source, public domain (free or low cost) implementations
> of the MHS with CPA support incorporated may make CPA/CPP implementation
> even more likely (but don't expect me to buy into the BPSS!).  On the
> down side, an SME still has to figure out how to fill out the CPP (by
> whatever means), and what to do when the automated negotiation of a CPA
> doesn't reach a workable conclusion.
>
> Your thoughts?
>
> --
> Michael C. Rawlins, Rawlins EC Consulting
> www.rawlinsecconsulting.com
>
> ----------------------------------------------------------------
> 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>

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh
tel;work:781-442-0703
x-mozilla-html:FALSE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh Najmi
end:vcard