Transactional QoS

Transactional QoS refers to the level of reliability and consistency at which the transactions are executed. Transactional QoS is crucial for maintaining the integrity of a Web service. Transactions are very important for business processes to guarantee that a set of related activities are treated and completed as a single unit of work. If an exception occurs while executing a transaction, the transaction has to be recovered back to a consistent state. This property is called the "atomicity" of a transaction. Other than property of atomicity, transactions in a stricter sense should satisfy consistency, isolation and durability properties. All these four properties are together called "ACID" properties (see the sidebar).

There are several approaches to provide transactional QoS. The most popular approach, which is traditionally used in Web application architectures is the two-phase commit. Two-phase commit provides a transaction coordinator which controls the transaction based on the idea that no constituent transaction is allowed to commit unless they are all able to commit. This approach of using a transaction coordinator to ensure atomicity is used in Java Transactional Service (JTS), CORBA OTS, and in most database management systems.

But there are new complications when we are thinking of transactions involving Web services. The Web services used by a particular application or Web service are often distributed remotely over the Web as well as owned by different parties. Having a central transaction coordinator, which dictates the rules and performs the commits and rollbacks, in a Web services environment is very tedious to implement considering the transaction coordinator does not have full control over all the resources. Also, two-phase commit protocol involves one or other form of resource locking. Longer periods of resource locking will result in serious scalability issues. Therefore even though it is possible to use, extreme care should be taken to make sure that resources are not locked for long periods of time.

The OASIS Business Transactions technical committee has released the Business Transaction Protocol (BTP) which extends the two-phase commit transaction management approach to address the needs of disparate trading partners that use XML to exchange data over the Web. BTP allows both the normal ACID transactions and non-ACID transactions (termed as "cohesions") for long lasting transactions that span multiple enterprises.

Another approach called compensation is based on the idea that a transaction is always allowed to commit, but its effect and actions can be cancelled after it has committed. For example, it may be possible to order a shipment, and then later cancel the shipment if the required shipment process has not yet started. Canceling the shipment is an example of a compensating transaction; it compensates for the initial transaction that ordered the shipment. In compensating transaction, each "real" transaction has an associated "compensating" transaction. This "compensating" transaction element describes a way to revert changes done by the "real" transaction and return to a previous consistent state. If any transaction aborts, the caller executes the corresponding compensating transaction for all the transactions that have previously committed. Two major problems associated with compensating transactions are:

• Compensating transactions, unlike two-phase commit, may not satisfy all the four "ACID" properties at all times -- this means there is always a probability for a failure.
• Traditionally designed two-phase commit transactions have to be redesigned to provide way for compensation.