A transaction may be thought of as a set of changes to the state of a system. All the changes must be applied together or none of the changes must be applied. For example, a transfer between two bank accounts involves two operations, debiting the payer's account and crediting the payee's account. In this case, if the credit operation fails we don't want to debit the payer's account because the money was not deposited in the payee's account.

We may have more than two changes in a transaction. For example, in addition to transferring the funds in our example, which requires two operations, we may also wish to notify the payer and payee that the transfer has occurred. Again, we want this to be part of the transaction because we do not want to send a notification unless the transfer of funds has also occurred, so we have now extended our transaction to four operations.

A transaction manager is responsible for coordinating the operations in a transaction. If all the operations are in the same resource, such as the same database, then the resource may manage the transaction itself. If the transaction is spread across multiple resources, such as the database and message queue, then an XA transaction manager is required to co-ordinate the operations across different resources.

SOA Suite by default will use the XA transaction manager in the application server to co-ordinate its transactions. When a message arrives in SOA Suite, an XA transaction is started.

Not all transactions are managed by a transaction manager. Sometimes we want the benefits of a transaction but the services we are using are non-transactional, for example basic SOAP over HTTP services. In this case, we need to manage the transactional behavior within our composites.

In our example, if the two accounts are held at two separate banking institutions, things could become more complicated. This does not change the transaction requirements; it just makes implementing a transaction more complicated. We must now provide explicit reversing transactions to undo unwanted work when we are unable to complete all the operations in our transaction. These are called compensating transactions.

Within SOA Suite, the BPEL engine has built-in support for compensating transactions that allow us to register and invoke reversing operations (compensating transactions).