SOA and distributed transactions?

Distributed transactions are used very often in SOA environments. If you've a composite service calling multiple services, the underlying service calls should be handled as a single transaction. Business processes should allow for a roll-back of their steps.

If the underlying resources allow for it, you can use 2-phase commits, but in many cases it is impossible. In these cases compensating actions should be done on the services/resources invoked before the failed step. In other words, undo the succeeded steps in a reverse order Imaginary example: telecom company provisions a new VoIP product for a customer with 6 service calls.

Distributed transactions are used very often in SOA environments. If you've a composite service calling multiple services, the underlying service calls should be handled as a single transaction. Business processes should allow for a roll-back of their steps.

If the underlying resources allow for it, you can use 2-phase commits, but in many cases it is impossible. In these cases compensating actions should be done on the services/resources invoked before the failed step. In other words, undo the succeeded steps in a reverse order.

Imaginary example: telecom company provisions a new VoIP product for a customer with 6 service calls: query inventory to check the customer has the right equipment configure customer equipment via mediation update inventory with new configuration set up rating engine to count CDR's for customer set up billing software to charge the customer with the correct price plan update CRM system with the result of the provisioning process The 6 steps above should be parts of one transaction. E.g. If inventory update fails, you (may) need to undo the customer equipment configuration.

Not really a case of when they make sense. A transaction (distributed or not) is implemented by necessity rather than arbitrary choice, to guarentee consistency. The alternative is to implement a reconcilliation process to ensure eventual consistency.In the classic bank example (money out of account A, into account B), transactional consistency is pretty much essential.

In some inventory systems (check inventory, decrement inventory, sell to customer), it may be acceptable for stock levels to be roughly accurate, rather than guarenteed. In which case, ignoring a failure (decrement inventory, sale fails to complete) could be dealt with by reconciling later.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.