Re: initial draft of CPP-CPA Specification

[David Russell <dr@bindsys.com>]

----- Original Message -----
From: "Bob Haugen" <linkage@interaccess.com>
To: "'Stefano POGLIANI'" <stefano.pogliani@sun.com>; "Todd Boyle"
<tboyle@rosehill.net>; "'Martin W Sachs'" <mwsachs@us.ibm.com>
Cc: <ebxml-tp@lists.ebxml.org>; <ebxml-bp@lists.ebxml.org>
Sent: Monday, January 29, 2001 1:44 PM
Subject: RE: initial draft of CPP-CPA Specification


> <Stefano Pogliani>
> My idea, I know, is far more low-level than the one promoted by Bob. Bob's
> assumption is that the REA model would be able to account for every kind
of
> transaction. I do not object to this, but I prefer to see the things from
a
> technical standpoint where "I do not care too much" of what is an economic
> event, I care about the choreography of commercial transactions described
in
> the Specification Schema, and each trx being one or more inpiut/output
> messages.
> </Stefano Pogliani>
>
> Actually, I do not think that the REA model can account for every kind
> of ebXML transaction.  In fact, only a small part of the REA semantic
> model is used in the ebXML metamodel. It only accounts for transactions
> with economic significance.  (But that is where the accounting and
> legal considerations apply.)
>
> The problem with taking a purely technical viewpoint is that you can't
> tell from the choreography when a transaction with economic
> significance has occurred unless something in the choreography
> tells you.  The document just received does not necessarily
> do the trick.
>
> Most of the time, the BSI will only want to send economic transactions
> to legacy systems when they have been confirmed or accepted.
>
> Similarly, if the BSI includes a mapping from ebXML transactions
> to legacy systems, for the common economic transactions it will
> be easier to map to and from a canonical model (i.e. the economic
> elements in the ebXML-BP metamodel) than to each variant of
> a document used in trade.  But that gets me past anything doable
> in ebXML 1.0.
>
> I continue to think my ideas are compatible with yours, though.
> We each want to think at a different level, but I believe strongly
> that both levels (technical and business semantics) are necessary
> to doing electronic *business*, as opposed to just file transfer.

It may well be worth considering that your approaches do
in fact highlight a more fundamental differentiation in the BSI space.

There seems to be agreement that the BSI performs a dual role,
both choreographer of the business process, as much a master of
business semantics as process workflow, and quite seperately being
in charge of isolating the actual Legacy world from the ebXML
infrastructure,
if I may borrow words from an earlier conversation.

It seems to me that a single framework intended to satisfy the requirements
of both roles may be problematic as the complexities (brought about by the
myriad of permutations of input/output triggers) involved in the latter role
(the interface to legacy) seems to be significantly greater.

The choreography of the business process is governed by the rules explicit
to the business process definition. As such events in this environment have
logical (or conceptually related at least) events from an economic or legal
sense.

The association of a printInvoice (legacy) to submitInvoice (BSI) event
makes sense, perhaps only if the the BSI Legacy interface is limited to
the same set of events that could be derived at the choreography level, ie.
the well defined 'significant' business events.

Otherwise there seems to be an arbitrary number of inputs and outputs (one
per
message required to arrive at a significant event) to the BSI on the legacy
side
and I'm not sure how these intermediate events may be described in an
interface
or if indeed  future interoperability is preserved when business process
definitions
evolve. The significant economic events may remain constant but the steps
required
to get there may not. This I need to think about some more.

I like your ideas, I'm just mulling over the scope of an eventual solution.
My two pence...

Regards,
David Russell

> Regards,
> Bob Haugen
>