Discovery of SOA patterns via Model Checking

1. Discovery of SOA patterns via Model Checking Authors: M. Di Penta, A. Santone, M.L. Villani

2. Patterns A design pattern describes a commonly recurring structure of communicating components that solve a general design problem in a particular context [Gamma et al.,. Design Patterns – Elements of Reusable Object – Oriented Software, Addison – Wesley, 1995.] • Why to use them • They document existing, well-proven design experience • To provide a common vocabulary and understanding for design principles • They support the construction of software with defined properties • ……

3. Patterns in SOA A SOA pattern describes a commonly recurring structure of communicating services … • Need to account for the new features of service-centric systems • Dynamicity: • partner services might not be decided at design time; • both services and their interactions can be defined dynamically. • Self-adaptation: • the system behavior adapts to specific execution contexts, e.g. user location and device • Self-healing: • recovery actions activated in case of problems/exceptions • Multiparty interactions: • e.g., many partner servicescan fulfill some request

4. Some examples op1_req op_req op_req op_req op_req S2 F Sn S1 S2 S1 P C Pq S1 C1 C S2 Sn C2 C S L Sn op2_req op1_req op1_resp op2_req op_resp op_resp op_resp op_resp op_resp op1_resp op2_resp op2_resp get_req AS op_resp op_req get_req op_resp log_op_req op_req op_resp log_op_resp Proxy FaÇade Load balancing Logger

5. Catalogues of SOA patterns • Patterns for service compositions [SeCSE A3D5, 2005] • Architectural Patterns • Workflow patterns [van der Aalst et al., Distributed and Parallel Databases, 14(1):5-51, 2003] • process control constructs, tasks synchronization, etc. • Service interaction patterns[Barros et al., Technical Report Queensland Univ of Technology, 2005] • how services communicate • synchronous/asynchronous bilateral interaction (direct or through delegation); • multilateral interaction, e.g., racing incoming messages; • multi-transmission interaction, e.g., if a request is not fulfilled by a service within a timeframe, that request is sent to another service; • routing, e.g., request with referral (a request to a service indicates some other services to which the response needs to be sent). • Service engineering design patterns[Milanovic, Proceedings of SOSE‘06] • Interpretations of classical design/architectural patterns • proxy and variations, faÇade, load balancer, logger • publish-subscribe • producer-consumer

6. Detecting SOA patterns • Static vs dynamic data • From the system implementation • Advantage • Accuracy: full knowledge of the system structure/code • Disadvantages • Applicability: the system implementation might not be available • Complexity: related to the size of the system • From the system logs built from SOAP messages • Disadvantages • Accuracy: the system structure has to be inferred, leading to probabilistic results • Advantages • Applicability: always applicable given logs availability • Complexity: analysis of the part of the system actually (or most frequently) used

7. Model Checking Detection through model checking • SOA patterns formalization • SOAP messages mapped to actions • Patterns specified by abstract TL formulas • System representation • Execution traces re-constructed from SOAP messages • Formal model built from trace analysis “Exact” identification of given patterns

8. Formal Languages c c] [ ff {a} a “it is not possible to perform c if has not been previously a c b performed” c] b [ tt a á ñ {a} Æ c a “for each , not preceded by b it is possible to perform preceded by any action ” • System Description Language: CCS • P ::= nil | a.P | P+P | P|P | P\L | P[f] | X • Properties Specification Language: Selective - Calculus* • (Branching)Temporal logic to express properties [Barbuti, De Francesco, Santone, Vaglini. Journal of Computer and System Sciences, 59(3), 1999.] •  ::= tt | ff |  |  | [K]R  | KR  | Z|νZ.|Z. FALSE TRUE

9. The approach

10. Example: the Proxy Pattern • Abstract Specification • A triple (C, P,(Si)) s.t., after each req_cp_msg from C to P • eventually P forwards it to some Si through the action req_psi_msg • before that P does not send a response to C nor can receive a response • after P has sent req_psi_msgto Si without having received another request, eventually it will receive a response resp_sip_msg from Si • dual constraints as above now holds for resp_sip_msg

11. Proxy Fault Tolerance • Variation of the Proxy pattern • What changes • Each message from C to P is concurrently forwarded to all the available services • This pattern is not a simple proxy if an execution trace exists where after req_cp_msg, eventually req_psi_msgis performed for more than one i

12. Case study: Image Manipulation Process

13. Deployment • Services and process distributed on two web server installations • SOAP Monitor • incoming/outcoming SOAP messages captured through a monitoring mechanism (using AXIS APIs) and stored on a DB

14. Method application: First check • Considered a set of logs covering all paths • Client represented by the BPEL process • Result • ProxyImageManipulation detected as serving role P in a proxy pattern

15. Image Manipulation Process Evolved • ProxyImageManipulation1 behaving as a fault tolerant proxy

16. Method application: re-do check • Added logs of second deploy of the system • Result • Both ProxyImageManipulation and ProxyImageManipulation1 detected as serving role P in proxy patterns • just one service among the candidates for bindings for ProxyImageManipulation1 operations

17. Method application: check again • Added more logs • Result • Only ProxyImageManipulation serving role P in a proxy pattern • e.g. proxy formula failed for operation executeAdd mediated by ProxyImageManipulation1

18. Related work • Most approaches developed for design patterns detection from code analysis • Non-formal or theorem-proving based approaches • Applicability of model checking-based techniques questionable because of the state explosion problem • Recent work on service-centric systems • Inference of web service interaction protocols from imperfect logs [Motahari Nezhad et al., Proceedings of ICDE, April 2007] • This work • First to tackle SOA patterns detection from SOAP message analysis • Uses model checking • Method validation on some examples

19. Future work • Improve limitations on concurrency • Model inference techniques • Analyze and formalize other patterns • More case studies • Compare and possibly combine the model checking “exact” approach with other approaches such as that by Tsantalis et al. [IEEE TSE, 2006], based on graph similarity scoring

20. Method application: account for data • Also consider valued CCS model (impose proxy service does not change input data) • each action name contains also data values • model check again on the valued model • Result • Operation executeDifference of ProxyImageManipulation1, caused failure of the valued proxy formula while true for the abstract model • one input data of the received request SOAP message was changed in the forwarded message