Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Atomic Service Transactions

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.


Nuwan Bandara

May 06, 2014

More Decks by Nuwan Bandara

Other Decks in Programming


  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 !