Organization for the Advancement of Structured Information Systems

Business Transaction Protocol
Primer

An OASIS Committee Supporting Document

Version: 1.0

3 June 2002

Copyright and related notices

Copyright © The Organization for the Advancement of Structured Information Standards (OASIS), 2002. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

________

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Acknowledgements

Employees of the following companies participated in the finalization of this specification as members of the OASIS Business Transactions Technical Committee:

BEA Systems, Inc.
Bowstreet, Inc.
Choreology Ltd.
Entrust, Inc.
Hewlett-Packard Co.
Interwoven Inc.
IONA Technologies PLC
Oracle Corp.
SeeBeyond Inc.
Sun Microsystems Computer Corp.
Talking Blocks Inc.

And contributions from the following individuals

Alex Ceponkus
Gordon Hamilton
Bill Pope

Development of this primer did not involve a formal and exhaustive review process of the kind used to fashion the BTP 1.0 Committee Specification. As a result it represents a looser consensus from which members of the OASIS BT TC and their companies might demur in particular respects.

The primary authors and editors of the primer were:

Mark Potts
Bill Cox
Bill Pope

Contributions to its writing were made by

Sanjay Dalal
Peter Furniss
Alastair Green
Mark Little
Sazi Temel
Jim Webber

Executive Summary

Increasingly an application is no longer a stand-alone entity.  Applications must access other applications and modify data held by other organizations to get their work done. 

As business interactions extend over the Internet, a protocol is needed to manage the interactions in that loosely coupled, asynchronous environment, where traditional techniques of resource locking no longer work. We show a detailed set of examples in a travel agency/travel provider scenario to illustrate many concepts of BTP in a real-world business environment.

The Business Transaction Protocol, or “BTP,” provides a common understanding and a way to communicate guarantees and limits on guarantees between organizations.  The formal rules are necessary for the distribution of parts of business processes outside the boundaries of an organization.   BTP solves part of the problem for developers of loosely coupled transactions—the coordination and forcing a consistent termination portions.  Expertise in the design of compensating actions is still required, but these compensations are local rather than distributed.

Table of Contents

Copyright and related notices

Acknowledgements

Executive Summary

Table of Contents

Introduction

Transactions in Loosely-coupled Systems

Requirements for Business Transactions

The Business Transaction Protocol

Goals and Motivation for BTP

Atoms and Cohesions

The Travel Scenario

Example 1—Single Party Atomic Transaction

Example 2—Multiple Party Atomic Transaction

Example 3—Single Service Type Cohesion

Example 4—Multiple Service Type Cohesion

Example 5—Multi Party Compound Transaction

Reading the Specification

Questions and Answers

References

Introduction

This document is a primer on the OASIS Committee Draft of the Business Transaction Protocol, BTP 1.0.  [BTP Specification]  We do not cover the entire protocol, but we do introduce much of the terminology.  We do not discuss the optimisations designed into the protocol (from the contributed base documents, even though they are an important factor in assuring high performance of the protocol.

We suggest that you read this Primer before reading the first section of the BTP Specification.  [BTP Model]

We first describe the environment in which BTP will function, define the goals of the Business Transaction Protocol, examine a set of related examples, and conclude with some questions and answers on BTP.

Transactions in Loosely-coupled Systems

Conventional transaction processing in tightly coupled systems supports the so-called ACID properties or guarantees—a transaction is

• Atomic: All or nothing.  If interrupted by failure, all effects are undone (rolled back).      
• Consistent: A consistent result is obtained, allowing clean state changes. The effects of a transaction preserve invariant properties.
• Isolated: Effects aren’t visible until all participants agree. A transaction’s intermediate states are not visible to other transactions. Transactions appear to execute serially, even if they are performed concurrently.
• Durable: The effects persist after the transaction is complete. The effects of a completed transaction are persistent; they are never lost (except in a catastrophic failure).

Unfortunately, maintaining all of the transactional ACID semantics in a loosely coupled environment is not practical —in part because of the need to use compensating transactions in certain cases, in part because of more complex failures.  Typical locking techniques introduce problems where the transactions may last hours, days, or even longer, so that complex lock management algorithms or new interactions need to be introduced.

Isolation is also an issue in a distributed environment, not least in that business issues argue against indefinite locking of resources.

ACID transaction processing, of course, works well in distributed environments today.  But the assumptions that make a network of Automatic Teller Machines work well are not present in coordinating a group of autonomous parties.  The ATMs are not autonomous in terms of the transaction protocol: they communicate with a centralized database; locking can be done within that database because the database is under the control of a single enterprise; and the loosely coupled ATMs wait synchronously for a transaction to proceed.

Finally, in distributed interactions, communication is less reliable.  Connections are intermittent, load plays a significant role in performance, and (in the case of wireless mobile devices) communications may fail altogether.

We have already described the ACID properties for [tightly-coupled] transactions.  Transaction semantics that work in a tightly coupled single enterprise cannot be successfully used in loosely coupled multi-enterprise networks such as the Internet.

The Business Transaction Protocol relaxes some of the ACID properties as summarized in the following table.

Requirements for Business Transactions

In this section, we will define BTP-specific terms and discuss how traditional transaction semantics can be weakened for the Internet.  Terms defined in the BTP Specification are in italics

As more organizations attempt to integrate heterogeneous environments with different transaction coordination semantics, both inside the enterprise and with business partners, a standard coordination protocol is required.  BTP is designed to allow the coordination of business transactions that span multiple participants ensuring that a transaction has a consistent without concern for whether the transaction spans disparate applications, developed with disparate technologies, and potentially deployed in different organizations.

In such circumstances, a single party does not control all the resources needed for a transaction.  We assume that each participant is autonomous and must manage its own resources while maintaining commitments it has made in a transaction.  This mirrors the real world of business, where there are varying degrees of privacy and control over how resources are committed and interactions managed, typically by negotiation.

In their autonomy, the participants in a business transaction may use recorded before- or after-images, or compensation operations to provide a “roll-forward, roll-back” capacity to enable coordination with respect to the overall outcome of the business transaction.  Locking can work for short-lived transactions, but compensation is more suitable for longer-lived transactions.

The Provider of a service decides when to commit/unlock, and when to compensate internal transactions/resources, but must provide both confirm and cancel mechanisms for commitments it makes.  The Provider decides how to meet its commitments; the Consumer manages the business transaction within the commitments made by the providers.  While participants have autonomous control of their resources, they must also offer some commitment to enable the coordinated and controlled termination of the business transaction.

BTP is a transactional protocol that allows independent participants and coordinators to negotiate commitment to a business transaction and allows implementations to manage those commitments to coordinate termination of the business transaction.

The Business Transaction Protocol

Today service providers often offer their commitments to a business transaction with caveats, or reservations.  But there is no standard protocol for those commitments to be made or managed to termination—the coordination and termination of these types of transactions requires out of band a priori agreement between developers on both the consumer and provider sides of the transaction.

The idea of negotiating commitment to transactions already exists in many situations today.  We will show realistic scenarios where commitments are made for a business transaction in a pessimistic or optimistic way.  For example, in the case of booking a flight, many providers take a pessimistic approach to their commitment to the transaction.

N.B.  We are using real company names in the following sections, in part to make the examples more realistic, and in part to defer (or even avoid) having to modify many graphics.

In the case of booking a Hotel Room, many providers take an optimistic approach to their commitment to the transaction.

BTP’s ability to coordinate between services offered by autonomous organizations makes it ideally suited for use in a Web Services environment, and as an underlying protocol for more loosely coupled business transactions semantics defined by conversation and process management standards. 

See the diagram on the next page.

Goals and Motivation for BTP

The OASIS Business Transaction Technical Committee was started to support business transactions that constitute units of work across multiple decoupled, distributed parties.  The protocol it has defined, the Business Transaction Protocol, is usually abbreviated BTP.  

BTP solves problems in environments with complex business interactions with potentially unreliable infrastructure over potentially unreliable communication links.  The goal of a typical business interaction is to provide a concrete completion or cancellation, under potentially complex business rules that need not (and can not) be understood by all participants.

More specifically, BTP goals include

·        Define a model for transactions across the internet, with participants from different organizations

·        Compose and coordinate reliable outcomes in the face of potentially unreliable communication channels and infrastructure

·        Manage the transaction life cycle

·        Support transactions between loosely-coupled systems communicating with each other asynchronously (for enterprise scalability and function)

·        Support long-running transactions that might last longer than any business will reasonably reserve its resources for another

·        Coordinate multiple related interactions

·        Provide a foundation for workflow and business modeling/execution tools

We will use a set of travel reservation examples in this Primer, as many of the problems solved by BTP are present in these common interactions.  For a more detailed description of the model of BTP, including a full discussion of error cases and optimizations, see Part One of the specification. [BTP Model]

Atoms and Cohesions

BTP Atomic Transactions, or atoms, are similar to transactions in tightly coupled systems, but the isolation property is relaxed, although the transactions are durable (see table below).  One atom coordinator and zero or more sub-coordinators coordinate a transaction; each manages one or more participants.  Participants act on behalf of services to either accept (confirm) or reject (cancel) the work done by the service within the scope of the atom. In addition, the outcome of an atom is atomic, such that all of the participants will either confirm or cancel.

Cohesive Business Transactions, the term for which is blended into the portmanteau word cohesions, similarly relax the isolation property, allowing the effects of a cohesive interaction to be externally visible before the interaction is committed.  In addition, a cohesion may deliver different termination outcomes to its participants such that some will confirm whilst the remainder will cancel. Finally, consistency is determined by agreement and interaction between the client (initiator) and the coordinator. The cohesive coordinator therefore has a more complex role than the atom coordinator.

Cohesions may consist of multiple sub-transactions; cohesions and atoms may have multiple participants, thus generating tree diagrams of relationships in a Business Transaction.

The Travel Scenario

To help explain the roles and interactions in the Business Transaction Protocol, we use the following scenario and variations for booking a trip.  The trip incorporates a flight, hotel, and car rental reservation and bookings.  The scenario covers a number possible outcomes and variations that show how BTP can be used to coordinate many different types of transactional interactions.

We will use this Scenario for five examples:

1. Single Party Atomic Transaction

Booking a Flight at UAL.com

2. Multi Party Atomic Transaction

Booking a Flight, Hotel and Car in one business transaction

3. Single Service Type Cohesion  

Price comparison of a flight through UAL.com, BA.com and Qantas.com, subsequently confirming the best option and cancelled the alternatives.

4. Multi Service Type Cohesion 

Booking a Flight, Hotel, and Car in one business transaction but including a price comparison for the flight portion through UAL.com, BA.com, and Qantas.com, and subsequently confirming one of the Flight options and Hotel and cancelling the Car bookings.

5. Multi Party Compound Transaction 

A Consumers view of booking a Flight, Hotel and Car in one business transaction through a Travel Agent Service, where the Travel Agent acts as an intermediary of the consumers behalf.

We indicate alternative steps with a decimal notation—for example, Stage 5.1, Stage 5.2, and Stage 5.3 might all be valid continuations from a Stage 4.

We do not discuss the optimisations designed into BTP (from the contributed base documents), even though they are an important factor in assuring high performance of the protocol.  Committee Specification describes the optimisations.  [BTP Specification]

Example 1—Single Party Atomic Transaction

This is the simplest of the four examples in the scenario but one that we will explore in depth to convey the roles, messages and sequence of those messages, the BTP protocol. As we examine the other examples we will be able to apply that understanding to the more complex examples without repeating all the lower level details.

In looking more deeply at this transaction, we will see the phases of the transaction, the message exchanges, and commitments made by the involved parties.

The Travel Agent now has 24 hours to make a decision about whether to accept and confirm the flight booking. After 24 hours UAL is under no obligation to honor its commitment. There are now three possible outcomes for the business transaction.

Example 2—Multiple Party Atomic Transaction

This example extends the Single Party Atomic Transaction case by adding more participants to the transaction. In the example below, the same interactions will exist, but this time the trip that we are booking includes multiple components not just a flight. Specifically this trip includes booking a Flight, reserving a hotel room and renting a Car. Without being able, to secure all three components of the trip we do not want to go ahead with the business transaction.

In BTP terms the transaction in this case is still atomic insofar as the participants will all see the same outcome: The Travel Agent needs to get agreement commitments to the business transaction and all the bookings need to either, complete successfully or fail, as a single business transaction.

We will not repeat the similar setup stages in the remaining examples.

Example 3—Single Service Type Cohesion

This example discusses a cohesion type transaction that relaxes not only isolation levels but allows for the relaxing of atomic properties prior to confirming or canceling a transaction. In this example, the Travel Agent chooses to start a transaction and book a flight to London. One flight option is direct on UAL and the other has two legs and two different carriers BA and Qantas. Eventually the travel Agent has to decide on one of the flights either the direct UAL flight or the combined Qantas/BA flight. By getting commitments for both the UAL flight or the combined Qantas/BA flight the Travel Agent can decide which to take knowing that they will always get the flight they decide upon as long as they make the booking compliant with any restriction made with the commitments received.

Given that the British Air/Qantas flights need to be taken as a pair, this example could be described with a sub-atom in the cohesion; we have chosen to instead describe business logic in a cohesion that has the same effect of booking either BA/Qantas in combination or United by itself.

Even though this business transaction is a cohesive transaction (cohesion), you will notice that the final set of participants chosen from the cohesion must terminate atomically. In the example BA and Qantas need to make commitment to the transaction and complete as an atomic set, omitting the UAL flight. Again, we could have shown this as a separate atom, but instead showed how to force this outcome from the cohesion.

Example 4—Multiple Service Type Cohesion

This example extends example 3 and discusses a cohesion type transaction that incorporates multiple service types and multiple services for those types. In this example, the Travel Agent chooses to start a transaction and book a vacation including Flight, Hotel and Car rental. The Hotel is specific to the location of the vacation (Perth Western Australia), the Car will be rented through Hertz, but the flight is variable—there are options on Qantas, BA, and United.

Example 5—Multi Party Compound Transaction 

In this example the Travel agent itself offers a service for other consumers to utilise for holiday and trip planning.  In effect, the travel agent is an intermediary acting on behalf of the consumer and the consumer never interacts directly with Qantas, Marriott, or Hertz.  The same type of interactions we have seen in the previous examples can be compounded or nested whether they are Atomic or Cohesive (in this simple example all portions of the transaction are Atomic) to support more complicated scenarios such as supply chain and intermediaries.  This example most closely reflects the real world of the travel agent.

Reading the Specification

The BTP specification and Model [BTP Model] more carefully and formally define the terms we are using here.  The BTP Specification describes many more potential topologies of actors, along with interaction diagrams, selected state transition diagrams, and detailed state tables.

Questions and Answers

In this section, we answer some common questions about BTP.

• Is BTP a Web Services protocol?  Where does it fit with Web Services?  BTP defines XML messages that can be exchanged over many carriers, including the SOAP/HTTP combination that typifies Web Services.  A binding to SOAP 1.1 over HTTP 1.1 is provided in the specification.  Providing transaction coordination for Web Services is one of the requirements for BTP.
• I’ve read about conversations for web services.  Does BTP implement conversations for pairs of parties? For multiple parties? BTP doesn’t implement conversations; binary conversations use a conversation identifier to keep track of the respective parties.  BTP can be used to aggregate binary conversations into multiparty conversations.   In a similar manner, binary agreements such as RosettaNet PIPs or ebXML Collaboration Profile Agreements could be built into multiparty collaborations.
• Does BTP attempt to do ACID transactions across the Internet?  No.  BTP allows the implementation of coordinated actions.  It is not feasible to do full ACID transactions between autonomous parties across the Internet—the locking constraints would tie up one party’s resources without giving them the control necessary to protect their business interests.
• BTP does 2-phase commit, but it’s not ACID.  Why?  BTP uses a 2-phase interaction between the service requestor and the service provider to ensure that participants and coordinators agree on the outcome of the transaction.  BTP neither requires nor expects the rigid locking of resources that is needed for ACID guarantees.
• Does BTP do 2-phase locking?  I understand that that doesn’t work well over the Internet.  BTP does not do 2-phase locking.  It is a 2-phase protocol, as there is a preparation and completion phase, but locking is not required for participants—they are autonomous, and locking of another entity’s resources is simply not acceptable in the BTP environment and model.

·        How is BTP similar to traditional transaction processing protocols?  BTP is similar to traditional transaction protocols in that it defines a consistent termination for a unit of work, called a transaction.  BTP has improved applicability to loosely coupled distributed transactions and environments with the required weakening of “tradition” transactional guarantees (e.g. ACID).

• Is BTP a workflow language?  BTP does not contain a workflow language. BTP can provide reliable outcomes for workflow systems for inter-related activities.  It enables more sophisticated workflows than might otherwise be possible, including reliable aggregation of multiple steps into a single unit of work. 
• Is BTP a business modelling language?  Is BTP a Business Process Language?  BTP is neither a business modeling language nor a business process language. As with workflow implementation, BTP can be used to ensure reliable outcomes.
• How much does an application writer need to know about BTP?  Applications that call BTP enabled services are required to interact with the BTP actors to initiate the communication (via the Initiator) and to bring the transaction to a close via the Terminator. Cohesion use requires further input and interaction from the controlling application to determine how the result set is formed.

Applications that provide a BTP enabled service need to call a BTP Participant to enrol in a transaction.  These service side applications need to implement some form of commit and cancel operations.  Whether these are compensation based or something else is up to the application writer.

Application developers who have been creating ad hoc termination protocols involving compensation will find their work simplified significantly.  While the nature of compensation actions requires significant expertise in the domain (such as financial services or workflow management), the developers’ job in creating termination and reconciliation protocols is much easier.

References

[BTP Model]   

Section 1, OASIS Business Transaction Protocol, Committee Specification 1.0. Download from http://www.oasis-open.org/business-transaction/

[BTP Specification]     

OASIS Business Transaction Protocol, Committee Specification 1.0.  Download from http://www.oasis-open.org/business-transaction/