SOA Patterns Webinar Series Atomic Service Transactions Nuwan Bandara ! Senior Technical Lead @nuwanbando May 6th 2014

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

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

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

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

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

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

The two phase commit protocol (2PC)

➡ When the transaction manager has control over underline resource managers ➡ When resource managers are implementing the XA standard Where do we use XA

Problems XA cannot solve ➡ Distributed Service oriented workflows ‣ One or more participating entities are out of control ‣ Legacy system interactions

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 ?)

➡ 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/

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

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 ?

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

Queued transaction processing ➡ Increases the durability of the transaction ➡ Suitable for multi transactional systems which has high fault probability

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

Distributed transactions with WSO2 middleware

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

Thank You !