Re: eBTWG BPSS Project Proposal

[bhaugen <linkage@interaccess.com>]

From: Maarten Steen
> I still don't understand though why transactions are not good enough to
communicate business commitment. For me a transaction is an atomic
interaction between two parties that results in a common understanding of
the state in the shared business process. Transactions can therefore be used
to
> communicate commitments, like "by placing this order I promiss to pay X
amount, and you promiss to deliver Y goods within Z days." If you don't want
to rely on documents or messages being exchanged in transactions, then how
else do you communicate commitment?

Maarten,

I know Dave is swamped with work right now, so please forgive me
if I jump in and try to respond.  We think alike on this, although
Dave sometimes explains better.

Transactions *are* good enough to communicate business commitment.
We're talking about managing the relationships between the transaction
that forms a commitment, and the subsequent transactions that
fulfill the commitment.

Our premise is that:

1. Monitoring the fulfillment of commitments is a major task
in the ongoing maintenance of B2B ecommerce operations,
as Dave can attest.  He now keeps several people busy
doing this.  Most of it could be automated if the ebXML
runtime software understood what to monitor.

2. The workflow style of choreographing business collaborations,
which all of the current crop of approaches seem to favor,
including BPSS, BPML, WSFL, XLang, whatever, is akin to
procedural programming.  Users will need to get into transitions,
transitional expressions, forks, joins, etc. etc.  There will be
bugs.

We think that much of the choreography of collaborations
can be made declarative by defining collaboration patterns
that already have the choreography built in.  Commitment
and fulfillment relationships will be the key building blocks
of the most useful collaboration patterns.  (Or so we think.)

Does that clarify?

-Bob Haugen