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 modifyhttp://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 !