The Business Transactions Protocol
So How Would I Use This BTP Thing?
Consider the flight-booking example presented earlier. How could we use BTP in order to coordinate this application in a reliable manner? The problem is that we wish to obtain the cheapest insurance quote as we go along and without losing prior quotes until we know that they are no longer the cheapest; at that point we will be able to release those quotes while maintaining the others. In a traditional transaction system, all of the work performed within a transaction must either be accepted (committed) or declined (rolled back); the required loosening of atomicity is not supported.
In BTP, however, we can use atoms and cohesions. A cohesion is first created to manage the overall business interactions. The business logic (application) creates an atom (ReserveAtom, say) and enrols it with the cohesion before invoking the airline and taxi reservation services within its scope, such that their work is then ultimately controlled by the outcome of the atom. When a suitable flight and taxi can be obtained, ReserveAtom is prepared to reserve the bookings for some service specific time. Then the insurance quotes are obtained by invoking their respective services within the scope of separate atoms (AtomQuote1 and AtomQuote2, for example), which are firstly enrolled within the controlling cohesion. When the quote from the first insurance site is obtained it is obviously not know whether it is the best quote, so the business logic can prepare AtomQuote1 to maintain the quote while it then communicates with the second insurance site. If that site does not offer a better quote, the application can cancel AtomQuote2 and it now has its final confirmation set of atoms (ReserveAtom and AtomQuote1) which it can confirm.
- http://www.oasis-open.org/committees/business-transactions/, June 2001.
- "CORBAservices: Common Object Services Specification", OMG Document Number 95-3-31, March 1995.
Dr. Mark Little is a Distinguished Engineer/Architect, within HP Arjuna Labs., Newcastle upon Tyne, England, where he leads the HP-TS and HP-WST teams. He is one of the primary authors of the OMG Activity Service specification, and is on the expert group for the work in J2EE (JSR 95) and leads the JSR 156 activity on an XML API for Java Transactions. He is HPs representative on the OTS Revision Task Force, and the OASIS Business Transactions Protocol specification. Before joining HP he was for over 10 years a member of the Arjuna team within the University of Newcastle upon Tyne (where he continues to have a Visiting Fellowship). His research within the Arjuna team included replication and transactions support (he is on the expert group for JSR 117), which include the construction of an OTS/JTS compliant transaction processing system.