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

[Adam Sroka <AdamS@rewardsplus.com>]

Title: RE: [ebxml-dev] ebXML CPA/CPP Estimate

 -----Original Message-----
From:   Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent:   28 November, 2001 11:45
To:     Eckenfels. Bernd; mike@rawlinsecconsulting.com; EDI-L, List; ebxml-dev
Subject:        RE: [ebxml-dev] ebXML CPA/CPP Estimate

Bernd Eckenfels writes concerning

Mike Rawlins> 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.

"This is especially true, if digital signatures and certificates are
involved. Those have to be exchnaged anyway. Therefore retrieving a CPP
may help, and having a CPA helps even more. On the other hand,
exchanging the CPA also requires a already working infrastructure, which
means, most of the parameters the CPA can deliver are already set up."

Dale Moberg> If there were no working infrastructure already,
do you really think these people were going to succeed in
collaboration? Most of the parameters are there in software to be
set up, true. But which way?

The CPP and CPA are exchange formats, Bernd,
and you seem to be missing this crucial point. Writing down
a CPP presupposes you have working software that implements
some portion of a specification's described capabilities.
This happens on both sides. Is there an overlap in that
set of capabilities?

Therein lies the limitation of CPP/A. There is assumed to be some level of agreement prior to actual engagement as to how this business is going to be handled. As you explain below, a basic interoperability can be derived from these assumptions. In legacy EDI these 'assumptions' are facts that must be established prior to any collaboration. ebXML is significantly more flexible, but not entirely so.

There is nothing wrong with this, however it is not a solution to all situations. I don't think that it should be. ebXML is not a standalone product in any sense. Rather it is a means of communication. The idea that some other layer of protocol might be necessary to establish a coordinated effort between two fundamentally different systems does not hurt my feelings (Am I the only one?) There are other initiatives aimed at this goal; BPMI.org is one suitable example. There are others that may or may not come to the forefront.

If so, you can write
down a CPA that expresses
the agreement for your interoperation in that collaboration
and send it to them out of band or, when possible, in
a to-be-defined light-weight communication mode.
Not a big deal to do perhaps, but useful. URLs are pulled out,
and service names, action names, PartyIds, and several
things to populate fields in ebXML messages. Retry counts,
time out intervals, persist durations, whether to use
digital envelopes, how the response is returned (whether
synch in a HTTP reply, whether asynch in some other
connection (URL for that?), or whether some mix. And that
is just a start. You may wish to make customers pick
and choose values for all those technical matters,
and then deal with the resulting support. And did I hear
you say you wanted this to roll out to SMEs?

"Instead of configuring a system with
lots of parameters from a CPP I
vote for specifying reasonable defauts
for all those parameters. This is
much more cost saving on the SMB case."

Gee Berndt, I don't know how we missed this!
Next time you should come to a meeting and
explain to everyone what the "reasonable defaults"
on all transport, acknowledgement, NRR,
reliable messaging, signals, signatures,
trust anchors, certificates, digital envelopes,
transport security should be for all types of
all business collaborations (from product
announcements to authorization for fund
transfer) for all variety of organizations
(government, educational,
Fortune1000, SME, midsize, and so on).
We could use your help! You might also find
out why this approach never works in practice,
and why we have _options_. Then you will understand
why we are trying to make configuration
of options easier, and to arrive at interoperable
solutions even when options exist. No wonder
you agree with Mike.

Regards,
Adam