Verifying Deadlock and Livelock Freedom in an SOA Scenario
1 like1,497 views
The document discusses a method for verifying deadlock and livelock freedom in a Service-Oriented Architecture (SOA) context using Petri nets. It presents a strategy to compute the most permissive partners and reduce fragments of the system's state space, allowing for efficient model checking. The approach aims to ensure system correctness by preventing message overflow and optimizing the composition of services.
![Partners Given service P, the set of (correct II)-partners has top elements in the simulation preorder One deterministic most permissive partner can be computed [Wolf, LNCS ToPNoC II] most permissive partner !€ !C ?B !€ !T ?B !€ !C ?B !T ?B ?€ ?C ?T !B !B !T !€ ?B !C !€ ?B .... !€ !€ !€ !T !T !C !C ?B ?B](https://image.slidesharecdn.com/acsd2009a-090914054210-phpapp02/85/Verifying-Deadlock-and-Livelock-Freedom-in-an-SOA-Scenario-7-320.jpg)
![Additional Idea Apply state space reduction collapse fragment-internal strongly connected components apply local reduction rules [Murata] Both preserve deadlock-freedom and livelock freedom](https://image.slidesharecdn.com/acsd2009a-090914054210-phpapp02/85/Verifying-Deadlock-and-Livelock-Freedom-in-an-SOA-Scenario-9-320.jpg)
Verifying Deadlock and Livelock Freedom in an SOA Scenario
- 1. Verifying Deadlock and Lifelock Freedom in an SOA scenario Karsten Wolf Universität Rostock Christian Stahl Eindhoven University of Technology Janine Ott Humboldt-Universität zu Berlin Robert Danitz Humboldt-Universität zu Berlin
- 2. Intro: Services Business Process Workflow net asynchronous Interorganisational Org 1 Org 2 Org 3 Service Petri net Initial marking Final markings Interface
- 3. Intro: SOA Petri net Service Provider Service Broker Service Requester Petri net publish find bind Once per Service Many times
- 4. Correctness (of Requester ⊕ Provider) Deadlock = non-final state without enabled transition Livelock = terminal SCC in state space without final state Message overflow = more than k messages of one type in a channel Correctness I (next talk): no deadlocks, no message overflow Correctness II (this talk): no deadlocks, no livelocks , no message overflow
- 5. Naive Approach Publish Store published service Find Compose Provider and Requester Model-Check AG (no message overflow) ⋀ AG EF final Most costs at Find
- 6. Our Approach Publish Compute fragments of state space (Provider ⊕ Requester) where no message overflow occurs Reduce these fragments Find Glue suitable reduced fragments Model-Check AG EF final Some costs shifted to Publish
- 7. Partners Given service P, the set of (correct II)-partners has top elements in the simulation preorder One deterministic most permissive partner can be computed [Wolf, LNCS ToPNoC II] most permissive partner !€ !C ?B !€ !T ?B !€ !C ?B !T ?B ?€ ?C ?T !B !B !T !€ ?B !C !€ ?B .... !€ !€ !€ !T !T !C !C ?B ?B
- 8. Main Observation ?€ ?C ?T !B !B !€ !€ !€ !T !T !C !C ?B ?B ⊕ = Every composed system can be built by plugging fragments and connectors, controlled by the simulation to the most permissive partner ?€ ?C ?T !B !B !€ !C ?B ⊕ = Fragment Connector
- 9. Additional Idea Apply state space reduction collapse fragment-internal strongly connected components apply local reduction rules [Murata] Both preserve deadlock-freedom and livelock freedom
- 10. Effect ?€ ?T !B !B !€ !C ?B ⊕ = ( )
- 11. Applied rules ... Remove redundant transition Collapse sequence Merge equivalent nodes Challenge: Local rules must be valid in every combination of fragements/connectors
- 12. Approach (Summary) Publish phase: Input: P Compute most permissive partner Compose them and extract fragments/connectors Reduce fragments and store them ?€ ?C !B !€ !€ !T !T !C !C ?B ?B ?T !B
- 13. Approach (Summary) Find phase: Input: R Find simulation to most permissive partner Compose corresponding fragments Modelcheck deadlock and livelock freedom !€ !€ !T !T !C !C ?B ?B !€ !C ?B !€ !C ?B
- 14. Experimental Results 04:41:09 2.1 3.6 14,073 24,688 494 19 160 Process IV 01:13:27 2.2 4.5 513 1,071 3,744 13 992 Process III 00:00:31 3.6 4.6 4,130 7,344 758 13 244 Process II 00:00:26 1.8 2.4 1,575 2156 468,072 20 97,511 Process I 00:00:09 6.0 320.0 112 2,239 2,927 6 1,057 Registration 03:43:13 3.4 10.8 4,082 13,148 34,947 12 8,345 SMTP Protocol 00:04:18 7.1 30.6 10,097 43,848 1,476 10 574 5 Dining Phil 00:00:01 2.6 7.5 172 499 70 6 46 3 Dining Phil 00:00:01 1.6 3.4 18 37 8 7 57 Beverage Mach. 00:00:05 2.3 11.0 16 77 744 8 308 Online Shop II 00:00:03 2.4 11.4 29 137 463 7 205 Online Shop I 00:00:23 2.0 2.3 570 672 11 12 10 Travel Service II 00:00:01 1.8 2.1 100 120 7 8 7 Travel Service I 00:00:01 1.6 2.1 25 33 6 6 6 Olive Oil Order 00:00:04 1.9 2.8 317 464 15 10 12 Purchase Order 00:00:01 2.1 6.1 15 43 33 6 26 Loan Approval hh:mm:ss St./Frag. red St./Frag. full St. red. St. full Trans. Mess. Types States Time P ⊕ most perm. partner(P) P Name
- 15. Discussion Size of fragments reduced to avg. < 10 Costs for find proportional to number of fragments = size of simulation Finding simulation is easy since most permissive partner is deterministic Model checking efficient Runtime peaks caused by checking application condition of a particular rule Time/Quality trade-offs possible A-posteriori state space reduction different from typical on-the-fly reduction Conclusion: Approach feasible