A Transaction Model for Web Services, Page 2
Business Transaction Protocol (BTP)
In May 2002, the OASIS Business Transaction Technical Committee (BTTC) published a specification, BTP 1.0, for coordinating transactions between applications controlled by multiple autonomous parties. BTP 1.0 is the work of several companies (BEA, IBM, Sun, HP, Choreology, ORACLE, and others) that addresses the challenges posed by business transactions to traditional transaction models.
Examining BTP messages and interactions in detail is beyond the scope of this book. Our intention is to describe the concepts and motivations behind BTP. The full BTP specification can be found at www.oasis-open.org/committees/business-transactions.
The BTP specification did not arise out of the need created by Web services architecture but was formed to address the needs of interorganizational transactions and of workflow systems. However, the authors realized early on the limitations of similar coordination protocols tied to communication protocols.
BTP defines an abstract message set and a binding to communication protocols. Its ability to coordinate transactions across multiple autonomous services and its use of XML messages makes it particularly suited for adoption in Web service architectures. BTP is designed such that the protocol may be bound to any carrier protocol, and BTP implementations bound to the same carrier protocols should be interoperable. The current specification describes a SOAP 1.1/HTTP binding.
Transaction and security aspects of an application system are often related, but the BTP specification consciously does not address how a BTP transaction will integrate with a security system, because Web services security standards are still evolving (independently of the transaction specifications).
Application and BTP ElementsBTP is a protocol—a set of well-defined messages exchanged between the application systems involved in a business transaction. Each system that participates in a business transaction can be thought of as having two elements—an application element and a BTP element (Figure 2).
Figure 2 Application and BTP elements overview
The application elements exchange messages to accomplish the business function. When Flute Bank's bill payment service sends a message to the check writing service with details of the payee's name, address, and payment amount, the application elements of the two services are exchanging a message.
The BTP elements of the two services also exchange messages that help compose, control, and coordinate a reliable outcome for the message sent between the application elements.
The application element pertains to the service consumer and service producer components the application programmer deploysthat is, application/business logic. The BTP elements are supplied by the BTP vendor. The separation of system components into BTP and application elements is a logical one. These elements may or may not coexist in a single address space.
With respect to a BTP transaction, application elements play the role of initiator (the Web service that starts the transaction) and terminator (the Web service that decides to commit or end the transaction). The initiator and terminator of a transaction are usually played by the same application element.
BTP elements play either a superior or inferior role. The BTP element associated with the application element that starts a business transaction is usually assigned the superior role. The superior informs the inferior when to prepare to terminate the transaction and waits for the inferior to report back on the result of its request. The following sections detail roles played by BTP elements and the nature and content of BTP messages.
Types of BTP Transactions
Table 1 summarized the transactional properties business transactions must satisfy. In all types of business transactions, the isolation property is relaxed. Some business transactions require the entire transaction to be treated as an atomic operation, while another class of business transactions requires that the atomic property also be relaxed. BTP accommodates both types of transaction needs. BTP Atomic Business Transactions, or atoms, are like traditional transactions, with a relaxed isolation property.
|In traditional transactions, a transaction manger will cancel (roll back) a transaction if any resource manager participating in the transaction cannot commit or cannot prepare. In BTP, this is not always the case; the set of participants that must confirm before a transaction can be committed is called a confirm-set. The confirm-set may be the set of all participants or a subset of participants.|
BTP Cohesive Business Transactions, or cohesions, are transactions where both isolation and atomicity properties are relaxed.
Atoms Atoms are business transactions where all participants have to agree before a transaction can be committed that is, all participants in an atom are guaranteed to see the same ending to the transaction. If any participant cannot confirm, the entire transaction is canceled. Because BTP transactions do not require strict isolation, it is up to each participating service to determine how to implement transaction isolation.
Figure 3 depicts a Web service consumer invoking two business methods on two different services, within the scope of a transaction. If the overall transaction is an atom, the BTP element (superior) at the service consumer end is called an atom coordinator or simply a coordinator. The BTP element plays the coordinator role and coordinates a BTP atomic transaction. It does this by exchanging BTP messages with the BTP elements associated with the two service producers when the application asks it to complete the transaction.
Figure 3 Application and BTP elements in an atom/cohesion
As Figure 3 also shows, inferior BTP elements are called participants. The participant is in charge of persisting the state change made by the associated application element (service producer), which it does by following instructions (via BTP messages) from the superior (coordinator). If either participant informs the superior that it cannot confirm the transaction, the transaction is rolled back—that is, the confirm-set in this example is "participant a" and "participant b."
|An atom is a BTP transaction whose confirm-set is the set of all inferiors—that is, in an atom, any inferior has power to veto the transaction.|
Page 2 of 5