1 / 21

A QoS-Oriented Reconfigurable Middleware For Self-Healing Web Services

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

peyton
Download Presentation

A QoS-Oriented Reconfigurable Middleware For Self-Healing Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  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]

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

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

  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.

  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

  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

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

  10. Considered QoS parameters Requester Provider t1 • 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] t2 Request Tresp Tcomm Texec + = Response t3 t4 Time

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

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

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

  14. Self-Healing Middleware modules : Diagnosis & Decision Interlocked web services Delay • (TexecWH>> TexecWH Avg) && (TexecSUP >> TexecSUPAvg) ==> 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]

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

  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

  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]

  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)

  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

  20. Thank you

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

More Related