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
Attachment Converted: "C:\PROGRAM FILES\EUDORA\Attach\najmi5.vcf"
