A Transaction Model for Web Services

So far, we have examined the properties, transactions, and specifications for transaction managers in the current Java/J2EE environment. Most, if not all, of today's Java transaction managers implement the flat transaction model, in compliance with JTA and/or JTS. Also, most transactions today are executed within the scope of one enterprise, within one trust domain, and with all resources under the control of one transaction manager. A business transaction may be defined as a consistent state change in the business relationship among two or more parties, with each party maintaining an independent application system (or Web service) that maintains the state of each application. Business transactions form a good number of transaction types in Web services.

While the flat transaction model is well suited for traditional business computing environments, a Web services environment can create new, interesting challenges for flat transactions:

• Loose coupling among services. A Web service application is a loose coupling of constituent Web services and is often constructed by combining Web services from multiple organizations. In this scenario, each service may implement a standalone business process and therefore demarcate transaction boundaries within the service. Because transactions are started and committed within each service, it is not possible to use a simple flat transaction model within the combined application.

  For example, in Flute Bank's bill payment service, Flute works with an external check writing service to mail payment checks on behalf of its customers. That is, when a Flute customer transacts with Flute's bill payment service, the service has to accomplish two separate functions as a part of one atomic transaction: it has to debit the customer's checking account, and it has to transact with the external check-writing service and send details of the payee (payee address, payment amount, etc.) If the external check-writing service demarcates its own transaction, a flat transaction model may be inadequate to guarantee atomicity to the Flute consumer's action. (The consumer's interaction is internally implemented as two distinct transactions).

  It should be said that a nested transaction model will accommodate this situation, but it is not the only model that can do so. A flat transaction model that supports interposition also can accommodate this situation; we look at interposition in the later sections that explain the Business Transaction Protocol (BTP).

• Long-running transactions. Many business transactions are long-running—some may run for hours or days. As transaction isolation is achieved by holding locks on resources, long-running transactions may reduce transaction concurrency to unacceptable levels. Moreover, in a business transaction, the actions of one party affect how long another's resources are locked, opening the door for denial-of-service attacks. It is clear that the isolation property (which controls locking) must be relaxed in such transactions.

  Because a business transaction can take a long time to complete, businesses often impose a time limit on certain types of transactions. For example, an airline may hold a tentative reservation for a travel agency for two days. When the time limit is reached, the airline may decide to either cancel or confirm the reservation automatically. The time period for timeout and the result (confirm or cancel) should be a business agreement between the two parties. The transaction protocol should anticipate such events and allow for negotiation between the participants.

• Optional subtransactions. In some business transactions, a subset of activities may be optional. An example of a fictitious travel agency will better illustrate such a situation.

  Assume that the travel service will search with multiple airline services to find flights, based on a consumer's request. Further assume that the airlines all take a pessimistic approach to their commitment: when the travel agent service requests seats on a particular flight, if enough seats are available, the airlines lock the seats for the travel agent and marks the seats unavailable to other requests. Figure 14.4 depicts the participants in this example.

  
  Figure 14.4: Atomicity relaxed, travel agency example

  In such a scenario, a transaction initiated by a consumer request will result in the agency requesting seats from one or more airline systems (in the example airlines A, B, and C), a rental car agency, and a hotel. Some airline systems may decline to participate in the transaction (perhaps because no seats are available, as is the case with airline C), and more than one may lock seats for the request (airlines A and B both have seats and confirm them).

  Airline C's failure to commit seats cannot be considered a failure of the reservation transaction as a whole, because the application can determine the atomic subset of participants, based on business logic. As a result, the atomic property of the transaction need not be satisfied. Moreover, should multiple airlines lock seats (Airlines A and B), a compensating transaction that releases previously booked seats will have to be generated for Airline B, so that only one airline eventually reserves the required seats. This, in effect, conceptually relaxes the durability property of the reservation transaction initiated by the travel service. For this solution to work, application logic has to be written to select the subset of activities that must be considered atomic and also to generate compensation transactions.

• Transaction context propagation. A Web service application that combines Web services from different organizations will have transactions that span the services. The constituent services may be implemented using different technologies on different platforms (e.g., UNIX, Windows) and may store state in heterogeneous databases. When a transaction spans these disparate services, the transaction context must be passed from service to service. In a JTS environment, JTS specifies how a compliant transaction manager propagates the context from one transaction manager to another over IIOP. A Web service transaction manager must accommodate XML-based transaction contexts propagated over Web service protocols.

This section has illustrated the need for a new model for transactions and transaction management. In the new model, a transaction is viewed as a series of business activities with the context of the transaction made available to each activity. The execution of activities is coordinated, but individual activities may decide to commit the effects of the transaction and make the effects visible before the larger transaction is completed. However, the flat transaction model is adequate for a large number of Web service applications—those that feature short transactions and those in which individual services persist data into a central database or databases within the same enterprise. The new model therefore has to support both the properties of ACID transactions and the relaxed ACID properties demanded by loosely coupled, long-running business transactions.

Strictly speaking, adoption of this new model is not dictated primarily by Web service architectures but by the fundamental long-running nature of business transactions. Web service architecture has simply accentuated the need for it.

Table 14.2 summarizes the differences between traditional transaction models and the new model.

Table 14.2: Properties of Traditional and Business Transaction Models

Property	Traditional transactions	Business transactions
Atomicity	Required; all or nothing.	Depends; sometimes desirable, sometimes may be applicable only to a subset of functions.
Consistency	Required.	Required; temporary inconsistencies rectified.
Isolation	Required; state change is not visible until transaction completes.	Relaxed; each service controls degree of visibility.
Durability	Required; effects persist.	Required, but based on atomicity property; some parts may be volatile.
Context propagation	Relaxed; may not be required.	Required.