JaVa
   

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 app system (or Web service) that maintains the state of each app. 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:

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 apps—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.

Java Start Sidebar

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.

Java End Sidebar

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.


JaVa
Comments