atomic service transactions
Post on 25-Jun-2015
683 Views
Preview:
TRANSCRIPT
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 !
top related