Atomic Service Transactions

Service-oriented systems are inherently distributed and often deal with transactional workflows. Transactions in distributed systems need careful design compared with traditional database-oriented transactions or monolithic application logic-based transactions. Ensuring ACID properties in a service-oriented system involve techniques such as two phase commits (2PC), transaction management systems, compensation mechanisms, and transactional proxies.

Transcript

1. SOA Patterns Webinar Series Atomic Service Transactions Nuwan Bandara ! Senior Technical Lead @nuwanbando May 6th 2014
2. What is a transaction ? ➡ A set of related tasks that needs to be executed to fulfill some purpose ‣ With regard to a database it would be executing a series of database operations to record a change in an application ‣ With regard to a business it would be performing a set of actions to fulfill a larger business operation
3. Whats most important about performing a transaction ? ➡ It has to be carried in full or not at all ‣ If its a business transaction, either the entire business process is completed or not
4. The key properties of a transaction ➡Atomicity ‣ The transaction must either commit or rollback all of its updates in a single unit of work ➡Consistency ‣ During the cause of an active transaction the system will not be left in an inconsistent state ➡Isolation ‣ How isolated the transaction is from other activities in the system ➡Durability ‣ If a transaction is committed, that execution is permanently recorded and will survive a system crash
5. When do you need transactions ➡ When one business operation depends on another ‣ Banking - Withdrawing money from an account ‣ e-commerce - Completing a product purchase and a delivery request ‣ Inventory control - record a fulfillment of an order ‣ Manufacturing - Production line activities ‣ Government - Issuing a social security number
6. Different transaction models ➡ Local transaction model - The underline source handles the transaction management. i.e the RDBMS or messaging provider ➡ Programatic transaction model - The programmer takes care of the transaction management. i.e committing, locking, rollback etc ➡ Declarative transaction model - The container takes care of transaction management ➡ The XA model - A dedicated transaction manager for managing distributed transactions ➡ WS Transactions model - SOAP WS based transactions ➡ Compensating model - Compensating operations for transaction management ➡ Try-Confirm/Cancel model (TCC) - A better compensating model for REST based architectures
7. X/Open XA standard for distributed transactions ➡ Example scenario - A stock trading activity to log a trade (a database update) and drop a message (Put into a message queue) into a different system that has an interest on the trade ‣ This is not a traditional transaction, the interaction is not limited to one source ‣ A middle man has to manage the transactions between the systems
8. The two phase commit protocol (2PC)
9. ➡ When the transaction manager has control over underline resource managers ➡ When resource managers are implementing the XA standard Where do we use XA
10. Problems XA cannot solve ➡ Distributed Service oriented workflows ‣ One or more participating entities are out of control ‣ Legacy system interactions
11. Business process management ➡ Isolation ‣ In a scenario where a user needs to transfer money from one bank to another (multiple transitions should work ?) ➡ Atomicity ‣ If the system fails after the money was debited from bank A ➡ Durability ‣ In a multi step transaction the state has to be remembered for recovery (logs / queues ?)
12. ➡ An involvement of a coordinator component at both application and service’s end ➡ Shared state ➡ Vendor dependent (Coordinator component is vendor dependent add vendor specific SOAP headers / low interop.) ➡ Low performance WS Transactions (WS-AT, WS-Coordination) http://specs.xmlsoap.org/ws/2004/10/wsat/wsat.pdf http://www.ibm.com/developerworks/webservices/library/ws-wstx1/
13. Compensating transactions ➡ Each forward step has an associated rollback operation ➡ Mostly used in business workflows (BPM/BPEL) ➡ Not compliant to ACID properties (Consistency is not guaranteed) ➡ Requires careful design ➡ Hard to maintain and modify http://msdn.microsoft.com/en-us/library/dn589804.aspx
14. Transactions with REST web services ➡ Why do you need transactions with REST ? ‣ Well I need to execute a series of correlated business operations over HTTP ‣ I also need to rollback changes to multiple locations safely and consistently if required ➡ Okay, but you cant do transactions over HTTP ‣ Huh… Seriously ?
15. Try-Confirm/Cancel protocol (TCC) ➡ Based on compensating model ➡ Uses a coordinating service ➡ Uses HTTP verbs for transaction execution ➡ Increased autonomy ➡ Uses the business state and decouples error handling
16. Queued transaction processing ➡ Increases the durability of the transaction ➡ Suitable for multi transactional systems which has high fault probability
17. Transactional middleware ➡ Mostly vendor driven {WSO2 / IBM/Microsoft / Tibco / Oracle} ➡ Dedicated middleware for transaction handling (e.g. Atomikos) ➡ Handles activities such as coordination, state management, persistence & queuing
18. Distributed transactions with WSO2 middleware
19. Bibliography • Principals of transaction processing, Bernstein, Philip A, 2nd Ed, 2009 • Java transaction design strategies, Mark Richards, 2007 ! • http://www.infoq.com/presentations/Transactions-HTTP-REST • http://docs.oasis-open.org/ws-tx/wstx-wsat-1.1-spec-errata-os/wstx-wsat-1.1-spec-errata-os.html • http://specs.xmlsoap.org/ws/2004/10/wsat/wsat.pdf • http://msdn.microsoft.com/en-us/library/dn589804.aspx
20. Thank You !