210 likes | 329 Views
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
E N D
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 • Issues/objectives • Contribution • QoS-Oriented Self-Healing middleware • Conclusion and Future work
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]
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
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)
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.
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
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
QoS Management: Diagnosis/Prognosis • Diagnosis (Our contribution: Proto1) • React to QoS degradation • Repair • Prognosis (Our contribution: Proto2) • Predict QoS degradation • Reconfiguration
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
A QoS-oriented Self-Healing middleware Monitoring (1) Analysis (2) Diagnosis & Decision (3) Repair (4)
Self-Healing Middleware modules : Monitoring (Synchronous) CheckAvailability (cerial, milk) QoS(t1,t2,t3,t4)
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
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]
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
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
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]
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)
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
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