Multi-Party Business Transactions paper

Bob Haugen of ebXML and UN/CEFACT Business Process work groups
and Tony Fletcher of same plus OASIS-Business Transaction Protocol
committee wish to announce a jointly-authored paper entitled
"Multi-Party Electronic Business Transactions"
available from (US letter page size):
http://www.supplychainlinks.com/UNCEFACT-papers.htm
or (A4 page size)
http://www.choreology.com/downloads/library.html

We think the paper is relevant to the discussions on this list
about business process coordination, transactions, choreography
(or opposition to choreography), convergence of competing
business process standards, and how to handle complex
multi-party business scenarios.

For example, the goal of our collaboration was to see
how much we could harmonize the workings of the
UN/CEFACT Business Collaboration Protocol (BCP)
and the OASIS Business Transaction Protocol (BTP).

We found that the two protocols had enough in common 
so that BTP-compliant software is able to execute 
BCP-compliant models for business collaborations 
and transactions.

We think that this finding will be significant for
the upcoming Web Service Choreography
Working Group.  It is a step toward the
convergence of the many competitors
for the role of Web business process
standard.

UN/CEFACT-BCP was derived from RosettaNet
and is the metamodel behind ebXML-BPSS.
And BTP participants have been working on
convergence between BTP and WS-T.
(E.g. other papers on the Choreology URL above.)
So observant readers can see evidence that 
all of these specifications can be harmonized.

For example, comparing BCP and BTP,
we found that each specification brought
something different to the views of the elephant, 
and then they had some overlap.  

BCP focuses on business semantics and coordination,
while BTP focuses on transaction completion
and recovery.  They overlap some on transactions.

Another of our findings was that the multi-party 
business scenario we considered required only 
pair-wise interaction.  

It did not require any third-party knowledge of these 
pair-wise interactions.  

Yes, multiple parties were involved in the whole scenario, 
but they interacted in pairs and all coordination between 
dependent commitments was the internal and private 
responsibility of only one party.

The paper lists several reasons why many parties
will want to separate into pairs:
* Simplicity - two is much simpler to handle than more-than-two.
* Accountability - business contracts may involve many parties, but
well-formed contracts always specify exactly who has agreed to do
exactly what for exactly whom (i.e., only two parties to each
contractual commitment).
* The more parties to a contract, the more parties have to agree on
everything. (And agreements about transaction rules are contracts.)
* Economic commitments and events involve two and only two parties.
* Security - need-to-know.  Trading partners need to know about each
other, but they rarely need to know what other partners each may have,
and in many cases should not know even that others exist.
* Decoupling to avoid ripples of change - if parties A and B change
their procedures, it may not affect parties C and D, unless all four
parties are bound into the same contract.

For more fun, read the paper.

Comments of all kinds sincerely welcomed.

-Bob Haugen and Tony Fletcher

Received on Tuesday, 3 December 2002 06:48:08 UTC