Intention:
Find a solution for distributed transaction management for system that interacts with multiple sub systems. Cover scenario for failures of environments, some system might be activities while others is failing, which does not satisfy ACID principles. There are mechanisms to handle these situations such as coordinated 2-phase commit (distributed transactions), but in the this solution is not really good when we spoke about distributed and scalable infrastructure."Sagas come out of the realization that particularly long-lived transactions (originally even just inside databases), but also far distributed transactions across location and/or trust boundaries can't eaily be handled using the classic ACID model with 2-Phase commit and holding locks for the duration of the work. Instead, a Saga splits work into individual transactions whose effects can be, somehow, reversed after work has been performed and committed."[1]
Description:
The term saga, in relation to distributed systems, was originally defined in the paper "Sagas" by Hector Garcia-Molina and Kenneth Salem. This paper proposes a mechanism that it calls a saga as an alternative to using a distributed transaction for managing a long-running business process. The paper recognizes that business processes are often comprised of multiple steps, each of which involves a transaction, and that overall consistency can be achieved by grouping these individual transactions into a distributed transaction. However, in long-running business processes, using distributed transactions can impact on the performance and concurrency of the system because of the locks that must be held for the duration of the distributed transaction. Saga as well is a failure management pattern.
A Saga is a set of rules for routing a job to multiple collaborating parties, and allowing these parties to backtrack and/or take corrective action in the case of failure.
As per above sequence is shown Fraud, Billing, Warehouse represented different system than saga is a distribution of multiple workflows across multiple systems, each providing a strategy of compensating actions in the event that any of the steps in the workflow fails, in another words as result of initialization of call we will get an rollback strategy.
Place of saga in SOA pattern:
Example of Implementation:
A great example of saga has been implemented by Clemens Vasters and posted on his blog. Have a look here: http://vasters.com/clemensv/2012/09/01/Sagas.aspx
Useful resources:
- http://vasters.com/clemensv/2012/09/01/Sagas.aspx
- http://arnon.me/2013/01/saga-pattern-architecture-design/
- http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/
- https://msdn.microsoft.com/en-us/library/jj591569.aspx
No comments:
Post a Comment