"In an SOA each functionality is separated as a service. So, a certain application may use many services to provide a defined functionality. The principles of SOA define services as a separate platform- and system-independent entities - each capable of functioning on their own, thus providing reusability and interoperability across disparate platforms."
There are various lifetimes of the transaction in SOA architecture (Transaction lifetime is the minimum of time that a transaction is kept open). A transaction could end in a few seconds or a couple of days! It depends on the underlying business requirements and implementation. Transactions with a short lifetime are easy to handle since the resources they use can be locked for the time required by maintaining the ACID properties. But the same strategy can't be applied to long-running transactions.
There are various scenarios which make the long-running process possible such as a transaction with lots of database queries, Batch processing and any kind of activity within the transaction. Batch processes run for long periods of time, usually for hours and mostly it only involves reading data. (in some cases it could contain modifying data). A failure during that operation would require an equally long rollback process.
Rather than all of the above notes, A long-running transaction creates a number of problems in an SOA architecture. As long as a transaction is limited to a closed environment, catching faults or exceptions and triggering the appropriate rollback mechanism can easily be defined in the underlying application architecture. in a distributed database environment these things can be taken care of.
For more information about the mentioned topic, you can refer these URLs:
- http://hydra.infosys.tuwien.ac.at/staff/zdun/publications/eplop06.pdf
- http://soa.sys-con.com/node/318438