1. Riadh BEN HALIMA Directeur de thèse: Khalil DRIRA LAAS-CNRS, Université de Toulouse, France A QoS-Oriented Reconfigurable Middleware For Self-Healing Web Services Journée thématique Composition d'objets, de composants et de services 27 Janvier 2008

2. 2 Introduction & context Issues/objectives Contribution QoS-Oriented Self-Healing middleware Conclusion and Future work Outline

3. Objectives for addressing QoS in WS-based applications QoS-aware Discovery (reputation) Description of offered WS QoS using ontologies for selection [Sanchez-Macian’06, Kritikos’06,Al-Masri’07] Contract Monitoring Invoicing, penalties between requester/provider WSLA, WSOL. [Keller’02, Tosic’05, Mahbub’07] 3

4. Objectives of QoS-based self- healing Preserve QoS during runtime in order to satisfy user requirements Build a self-healing system Monitor the system “health” Diagnose QoS degradation Reconfigure system when necessary 4 In a seamless way to requesters and providers

5. Monitoring & Repair: QoS management levels (Execution/Communication) 5 WS Requester WS Provider Execution-level Communication- level SH-BPEL (Polimi) JBPM (Unito) SOAP-level (LAAS proto1) HTTP-level (LAAS proto2) Extend WS container with logging capabilities Insert interceptors between R & P Self-healing middleware

6. QoS Management: QoS application levels (instance/class) Instance-level: Deal with requests related to the current running process Handle functional characteristics based on orchestration process description Repair actions: Redo-Retry, Compensate, Adjust, Skip, etc… (extension of BPEL) Class-level: Deal with all requests (Our contribution) Handle QoS characteristics degradation based on QoS attributes of communication messages (SOAP level) Repair actions: Substitute, Duplicate. 6

7. QoS Management: Targeted services (stateless/stateful) Stateful: Conversation state between operations call is retained and saved State information is a part of the exchanged data between the provider and the requester (generally in SOAP Header). Require state’s transfer while reconfiguring targeted services Stateless: No state between service operations call (Our contribution) No need for special management of header information 7

8. Monitoring & Diagnosis: Local/global Local: Related to a pair of provider-requester (Our contribution: Proto1) Handle only synchronous communication Limited view of the system Global: Related to several pairs of providers and requesters (Our contribution: Proto2) Handle both synchronous and asynchronous communications Handle degradation propagation and avoid over- reactions and useless reconfiguration actions 8

9. QoS Management: Diagnosis/Prognosis Diagnosis (Our contribution: Proto1) React to QoS degradation Repair Prognosis (Our contribution: Proto2) Predict QoS degradation Reconfiguration 9

10. Considered QoS parameters Execution Time: The time that the provider needs to achieve the processing of the request: Texec = t3 – t2 Response Time : The time between sending a request and receiving the response: Tresp = t4 – t1 Communication Time: The time that the SOAP message needs to reach its destination: Tcomm = Tresp – Texec Other QoS attributes: Throughput, Availability, Scalability [Menascé’04, Saddik’06, Rosenberg’06] 10 RequesterProvider Time t1t1 t2t2 t3t3 t4t4 T exec T resp T comm + = Request Response

11. A QoS-oriented Self-Healing middleware 11 Monitoring (1) Diagnosis & Decision (3) Repair (4) Analysis (2)

12. Self-Healing Middleware modules : Monitoring (Synchronous) 12 CheckAvailability (cerial, milk) QoS(t1,t2,t3,t4)

13. Avg Avg+D Acceptable values Chronicle is triggered with N=3: t1,t2,t3>Avg+D Chronicle is not triggered with N=3 Texec t2 t1 t3 Key: Monitored Texec On-the-fly computed Avg value On-the-fly computed Avg + Tolerateddelay value On-the-fly computed average (Avg is deduced from current QoS parameter values) D=Tolerated delay Chronicle is triggered with N=3: t3">t2”>t1” Chronicle is triggered with N=3:t1’,t2’,t3’>Avg+D Time t1" t2" t3” " Pre-computed average (Avg is deduced from large scale experiments, Avg=Constant) Interval “I1" N successiveTexecViolationN inthe interval “I1" Nsucessive increasing ofTexec t3' t2' t1' Self-Healing Middleware modules : Analysis 13 TexecViolation  Texec> Avg+D

14. Self-Healing Middleware modules : Diagnosis & Decision 14 Interlocked web services ( Texec WH >> Texec WH Avg) && (Texec SUP >> Texec SUP Avg) ==> Degradation detection Local_Diag(WH1)==>WH1 QoS degradation && Local_Diag(SUP1)==>SUP1 QoS degradation Substitute (WH1,WH2) [WH2 equivalent to WH1] && Substitute (SUP1,SUP2) [SUP2 equivalent to SUP1] Global_Diag(WH1,SUP1)==>SUP1 QoS degradation ( WH1 degradation is due to degradation propagation ) Substitute(SUP1,SUP2) [Where: SUP2 equivalent to SUP1] Delay

15. Self-Healing Middleware modules : Repair 15 Requester-Side Monitor, 4: M3 9:ReqMes WH1 Key: SUP1 Virtual WS Diagnosis WS Prognosis WS Connector Generator WS Dynamic Binding Connector Deployment WS LoggingWS Analysis WS Decision WS SequenceNumber:MessageName:=Contentn:M:=(C1..Ck) 1: M1 2: M2:= (M1, QoSP1) 3: M3:= (M2, QoSP2) 6: M4:= (RespM1, QoSP1,QoSP2) 7: M5:= (M4,QoSP3) 8: L1:= (QoSP1,QoSP2, QoSP3, QoSP4) 8: RespM1 10:RespMes 11:Alarms 13: Decision 12: Report Provider-Side Monitor SUP2 WSDL Compiler Connector Code Generator Java Runtime Compiler Internal components of the "Connector Generator WS" Connector code SUP2 WSDL Stub code DBC Substitute(SUP1, SUP2)

16. Summary (1/2): QoS prototype implementation Prototype V1: [IEEE ISWS/WETICE’07] Acts on SOAP level Extend the Axis APIs (mange SOAP Header at the container level) Extend Handlers with monitoring/reconfiguration capabilities Implements: Local Monitoring, Local Diagnosis Reconfiguration based on the Dynamic Binding Connector Prototype V2: [ICEIS’08] HTTP Proxy: Monitoring and Reconfiguration Socket based programming Global Monitoring, Local Prognosis (HMM) Graphical monitoring window Build and visualize all interactions between all the WSs that use the HTTP Proxy 16

17. Summary (2/2): QoS-related studies and models Algorithms and frameworks: Analysis & Global Diagnosis algorithms of QoS degradation [IEEE ICADIWT’08] Global Monitoring & Reconfiguration algorithm and framework: [IEEE ICWS’08] Integration architecture for class-level and instance- level self-healing [DMVE/DEXA’08] Models Degradation detection (for Analysis) and source identification (for Diagnosis) chronicles [D3.2 & JIAS] Hidden Markovian Model for prognosis [ICEIS’08] 17

18. Future Work Implement the Global Diagnosis algorithm in the prototype V2. Extend with Automated Service Discovery for reconfiguration Analyze performance of V2 for a large scale application Implement integration of class-level and instance-level self-healing Improve the configurability of the prototype: provider API and GUI Apply to other SOA technologies like OSGI Generalize for additional QoS parameters Automatic generation of QoS monitors based on a semantic information by annotated WSDL. (SAWSDL) 18

19. References [IEEE ISWS/WETICE’07] Riadh Ben Halima, Mohamed Jmaiel, and Khalil Drira. A QoS-driven reconfiguration management system extending Web services with self-healing properties. [D3.2] Specification of execution mechanisms and composition strategies for self-healing Web services. Phase 2 [IEEE ICADIWT’08] Riadh Ben Halima, Karim Guennoun, Mohamed Jmaiel, and Khalil Drira. Non-intrusive QoS Monitoring and Analysis for Self-Healing Web Services. [IEEE ICWS’08] Riadh Ben Halima, Mohamed Jmaiel, and Khalil Drira. A QoS-Oriented Reconfigurable Middleware For Self-HealingWeb Services [ICEIS’08] René Pegoraro, Riadh Ben Halima, Khalil Drira, Karim Guennoun, and Joao Mauricio Rosrio. A framework for monitoring and runtime recovery of web service-based applications. [DMVE/DEXA’08] O. Nabuco, R. Ben Halima, K. Drira, M.G. Fugini, S. Modafferi, and E. Mussi. Model-based QoS-enabled self-healing Web Services. [JIAS] Riadh Ben Halima, Karim Guennoun, Mohamed Jmaiel, and Khalil Drira. Providing Predictive Self-Healing for Web Services: A QoS Monitoring and Analysis-based Approach. Selected from IEEE ICADIWT’08 for publication in Journal of Information Assurance and Security 19

20. Thank you 20

21. The HMM is a tupla, where: S is the set of states; S = {Working, Partially Working, Not Working}; A is the transition probability distribution among the states, a ij = P[ s j at t+1 | s i at t ]; V is the set of observable variables; V = {v k }; and B is the current probability distribution of observe v k being in s j. b j (k) = P[observe v k | s j ]; And π is the initial state distribution π = {π 1, π 2,..., π N }. Self-Healing Middleware modules : Prognosis & Decision 21 Estimation of the state distribution at the instant t+1 State distribution at the instant t