Transaction Management in SOA

Question

SOA services should self contained services, but in practice we need to orchestrate these services to perform some business/process.

Now, for a process & data to be consistent, we need to ensure all the services are executed or none is executed.

One way to implement is to implement "compensation" logic for each service and call it if some problem occurred in the process/previous service.

Is there any better way or some standard to do the same, for example, taking out the transaction context and implement something like 2 phase commit?

Answer 1

It does depend on the services that you are accessing. In some you will have no way to perform compensation, whilst in others you will have no way to control the transaction, and in others you will have no alternative whatsoever.

Both compensation handlers and 2 phase commit (XA transactions) are both valid mechanisms for managing transactions.

Consider the services you are interfacing to, and what type of support they offer. For example if you have a large number of web services you may not have the transaction control that XA will give you, but they may have a mechanism for reversing an operation.

In a perfect world you would have 2 phase commit which would reduce the compensation required but interfaces are interfaces, and like people to people, communication will vary and there is no one perfect solution.

When designing interfaces make consideration of transaction control and compensation recovery as part of your interface design and you will be praised (or at least not criticised) for creating a useful interface.

Answer 2

You can use Fault Handlers and Compensation Handlers defined in the WS-BPEL 2.0 Specification (which is a standard that offers a way to describe and orchestrate interactions between Web Services) so it separates business logic from the compensation logic in a standard way.

• Link to Error Handling in BPEL Spec
• Blog post on how to write a compensation handler in BPEL