[business-transaction] BTP thinking applied to UN/CEFACT work

[Tony Fletcher <tony_fletcher@btopenworld.com>]

Title: Message

Bob Haugen of ebXML and UN/CEFACT Business Process work groups and Tony Fletcher (Choreology) 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

The paper shows how the thinking that went into BTP can influence other standards that have come at the need for transactions from a different angle, and how the Business Transaction protocol itself can be used as an 'underlay' for application protocols, even when not initially considered.

The paper is relevant to discussions about business process coordination, transactions, choreography, convergence of competing business process standards, and how to handle complex multi-party business scenarios.

One goal of our collaboration was to see how much we could harmonize the workings of the developing 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 would be able to implement the business collaboration/transaction patterns required by the UMM and which are part of the current Business Collaboration Protocol effort."

 

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.

With best regards from Bob Haugen and Tony Fletcher

                       

	Tony Fletcher Technical Advisor Choreology Ltd. 13, Austin Friars, London EC2N 2JX UK
	Phone:	+44 (0) 20 7670 1787
	Mobile:	+44 (0) 7801 948 219
	Fax:	+44 (0) 20 7670 1785
	Web:	www.choreology.com
Cohesions 1.0™
Business transaction management software for application coordination
Work: tony.fletcher@choreology.com
Home: amfletcher@iee.org