Transactions for Web services-Part I

What is Transaction?

A transaction is a unit of work that involves one or more resources and is either completed in its entirety or is not done at all. Participating resources are locked for the duration of the transaction. Depending on the readiness of all the participating resources, the changes made to the resources are either committed or rolled back, and the lock is released.

   To further understand the transaction let’s take a look at real life example of Net Banking, suppose you want to transfer some money from your own account to your

mother’s account this process of transferring money from one account to another

can be viewed as made up of following main tasks

1)      Debiting specified amount from your bank account ledger 

2)      Crediting same amount into your mother’s  bank account ledger 

Transferring process will be complete only if both task completed successfully not otherwise. This means transfer of money from one account to another fulfill criteria of being a transaction.

   Most of the ecommerce sites rely on other third-party services for as a part of there business process e.g. consider an example of air ticket booking sites like

www.yatra.com or www.makemytrip.com usually to get best air ticket deal to there customer these site need to interact with different airlines having there own ticket booking facility through there own systems. Ticket for given seat in given airline on given date time should be booked at most once. Money transaction from customer to

air ticket booking site should be completed successfully that also depend on third party payment gateways like say PayPal.

      In such scenario we need to ensure that process completed in its entirety or is not done at all. Locking of resources of one party from other will concede control of once resources to other, making participating parting susceptible to Denial of Services attack situation demand transaction that may not necessary fit into ACID Property that we usually associate with Database transactions.

  

Compensation-based transactions
Let’s imagine a service composition that invokes a decision service to validate request data, proceeds to update a customer entity via an entity service, and then sends a message on a queue for an external process to consume. Consider the three steps as part of a single unit of work – a service transaction that execute in sequence.
   If runtime exceptions associated with the composition are unhandled there is an increased likelihood of compromising data and business integrity. The compensating service transaction pattern introduces additional compensation steps in order to handle runtime exceptions without locking system resources. These additional steps can be included as part of the composition logic or made available as separate undo service capabilities. Continuing the earlier example, a call to undo the customer update (essentially resetting the data back to the earlier state) can be made to place the underlying data in a valid state.
The compensation-based transactions have the following salient features:

• Ability to manage consistency of data across applications without locking resources
• Coordination of various transaction participants without giving complete authority to a central transaction manager
• Ability to work in scenarios where participants' availability and/or response is not guaranteed

The above features are based on Web Services-Coordination/Web Services-Transaction (WS-C/T) specifications.

It is necessary to ensure that the compensating steps themselves execute successfully. Error alerts/notifications may need to be sent in case compensations fail and manual interventions are needed.

The Compensating Service Transaction pattern provides several benefits:

• Eliminates the need for executing distributed service invocations within a transactional context.
• Provides a mechanism for services/resources that don’t support atomic transactions to participate in service compositions.
• Reduces load on underlying systems and databases by only invoking compensation routines when failure occurs. Instead of locking resources in case failures happen, the idea is to handle runtime exceptions when they actually occur.
• Allows reuse of compensation steps across service compositions. E.g. two business services that update a data entity can reuse the undo Update capability.

Reference:

1)      http://www.ibm.com/developerworks/xml/library/x-transws/

2)      http://en.wikipedia.org/wiki/Compensating_transaction

3)      http://artofsoftwarereuse.com/tag/compensating-transactions/