Transactions are a common, everyday occurrence in our lives. When you buy something at the grocery store, transfer funds between bank accounts, or simply make a phone call you are executing a transaction. In general terms, a transaction involves one or more changes in state. For example, purchasing groceries involves many state changes. You debit your credit card while the grocery store reduces their inventory. Together, these changes represent a transaction. The together part is important since you wouldn't want to pay unless you actually got to take the groceries home. So, we can define a transaction as a group of state changes (or activities) that must be completed as a unit - all activities succeed or fail together.

ACID Transactions
Database management systems are most commonly associated with transactions. A transaction in a relational DBMS allows changes to any number of tables to be treated as a single, atomic action. This is achieved by locking rows until all changes have been made successfully or until an error occurs, which causes all changes to be rolled back, to their previous state. Database transactions are typically referred to as ACID transactions as an acronym for the guarantees made - Atomic, Consistent, Isolated, Durable. You can find a detailed explanation in most database reference material.

Databases aren't the only systems that implement transactions. Enterprise systems, including parts of J2EE such as EJBs and JMS, use ACID transactions. The Java Transaction API (JTA) and Java Transaction Service (JTS) implement them. Client/server systems also require transactions but add the special wrinkle that the activities and state changes that compose the transaction span multiple machines, networks, and enterprises. Like transactions in a database, distributed transactions are ACID transactions where resources are locked until all activities complete successfully.

Business Processes and Transactions
The Internet has changed the way businesses exchange information. New technologies like XML and Web services provide the data format and communication infrastructure that enable business partners to easily exchange data. Businesses use these new technologies within a broader integration framework, like BEA's WebLogic Integration 8.1, to build sophisticated applications that execute a complex choreography between business partners. These applications are referred to as business processes.

Business processes use transactions to ensure that all activities complete as a unit. But because activities in a business process utilize resources from many business partners and can execute for hours, days, or longer, the transactions must be managed differently. Consider a purchasing business process. It might solicit quotes, reserve inventory, issue purchase orders, confirm receipt of items, and transfer funds. For scenarios like this, using a single ACID transaction for the entire business process is impractical. Business processes require a new kind of transaction.

Long-running transactions avoid locks on non-local resources, use compensation to handle failures, potentially aggregate smaller ACID transactions, and typically use a coordinator to complete or abort the transaction. In contrast to rollback in ACID transactions, compensation restores the original state, or an equivalent, and is business-specific. The compensating action for making a hotel reservation is canceling that reservation, possibly with a penalty.

A number of protocols have been specified for long-running transactions using Web services within business processes. WS-Transaction with WS-Coordination, OASIS Business Transaction Processing, and WS-CAF are examples. These protocols use a coordinator to mediate the successful completion or use of compensation in a long-running transaction.

The Future
Efforts to standardize business processes like Process Definition for Java (JSR 207) and OASIS' WSBPEL will drive the creation and acceptance of standards for long-running transactions and compensation. Working with long-running transactions, these technologies will expand a business's ability to share and execute business processes with and among its trading partners.

Reproduced with permission from BEA Systems

Author Bios
Rich Rollman is a senior engineer on the BEA WebLogic Integration team and the Specification Lead for JSR 207 (Process Definition for Java). He has been involved with the development of XML and Web services since their inception and has 20 years of experience with client/server computing. richard.rollman@bea.com.

William Cox is a technical director in the BEA CTO Office, concentrating on transactional and portal architecture. He is a coauthor of BTP, the BTP Primer, and WS-Transaction. He holds a Ph.D. in computer sciences from the University of Wisconsin-Madison. william.cox@bea.com.