Main Page

Previous Section Next Section

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:

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.

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

Table 14.2: Properties of Traditional and Business Transaction Models


Traditional transactions

Business transactions


Required; all or nothing.

Depends; sometimes desirable, sometimes may be applicable only to a subset of functions.



Required; temporary inconsistencies rectified.


Required; state change is not visible until transaction completes.

Relaxed; each service controls degree of visibility.


Required; effects persist.

Required, but based on atomicity property; some parts may be volatile.

Context propagation

Relaxed; may not be required.


Previous Section Next Section

JavaScript Editor Java Tutorials Free JavaScript Editor