A Conflict Resolution Control Architecture for Self-Adaptive Software Prof. A. Taleb-Bendiab School of Computing and Mathematical Sciences Liverpool John Moores University {cmsnbadr, d.reilly, a.talebbendiab}@livjm.ac.uk http://www.cms.livjm.ac.uk/except A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 1
Dependable software • Autonomic computing: a recent trend – Devolving software management, maintenance to software • Self-organising, self-healing, sentient, self-adaptive, self-aware, etc. – Requiring meta-systems and meta-reasoning to; • Continuous measurement and/or reflection on operational systems • High-assurance: high-{integrity, availability, etc.} – Complexity and uncertainty hiding through; • adaptive capability to respond to changes including: fault&intrusion- tolerance, thus masking errors, failures, etc. • Dynamic architecture transformation and reconfiguration strategy; – This requires reasoning and consideration of a set of concerns; » software architecture model including; components and their interactions, the properties and policies, » Style and composition rules and/or norms that limit the allowable systems adaptation operations. A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 2
Integrity Management • Dynamic architecture transformation often lead to inconsistencies and conflicts – Systems integrity – Quality of service, etc. • Requirement for a software adaptation engine with; – Conflict detection and identification – Conflict resolution • Solution generation, negotiation • Change plan enactment, etc. – Control strategies defining; • Transformation rules, regulations, patterns, etc. • Our approach is a middleware to support for self- adaptive software conflict management. A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 3
Related Work • Self-Adaptive Software – Can be defined as software with computational reasoning capabilities to monitor and change its own structure and/or behaviour to adapt to its operating environment and recover from errors. • Reflective middleware • Dynamic configuration control and management • Conflict resolution – Negotiation Protocol – Exception handling A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 4
Reference Model #1 Management Unit V Environment System V V Key V = Variety = Attenuation = Amplification A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 5
Reference Model #2 Intentions System Five Desires World Model Deliberation Process Intentions Internal Model Surviving Plans Overall Schedule Monitoring to next recursion Filtering Process Plans Status Environmental Opportunity Scan Analyser Internal Model System Four Intentions Planning Process Further possible Plan managerial Activities Library Monitoring data Reasoner Scheduling Overall Plans Operational Resource Status Bargaining Process Accountability System Three R Overall Schedule Intentions e s o u r c e s Local Monitoring data Local Plans Local Monitoring data Local Monitoring data Local Schedule A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 6
A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 7 Application Applications Supporting Application Services Development Support Services REGISTRATION SERVICE An Architectural Model C O M A1 SERVICE LOOKUP A1 CONFIGURATION SERVICE A1 OPERATIONAL SERVICE JINI SERVICES ASSEMBLING SERVICES MONITORING SERVICE C O M B1 JavaSpace MANAGEMENT B3 B2 CONTROL B4 MECHANISM BROKER COMMUNICATION SERVICE
Adaptation Usage Model Services Supplier Monitor Service Instrumentation Service Diagnose Service Service Service Manager Registration Service Service Proxy Remote Event Utility System Constraint Checker Exception handler Utility Conflicts Repair Strategies Service Manager Proxy Client Remot e Reconfiguration Client Proxy Event Service Adaptation Strategies Boundary of Control mechanism Jini Lookup Service (LUS) A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 8
An Example: E-Fire Services A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 9
Example Programming Model Service Manager Vehicle 3-in-1 Information AVL Operation Phone Systems Vehicle Walkie Database/ Incident Power WAP Cellular Recorder Talkie XML Servlet Response Management 5 Monitor Monitor Monitor 1 Client 3 Mgr1 Mgr2 Mgr3 Reconfiguration Diagnose Diagnose Diagnose Service Management Service Manager Service Manager Service Manager 2 Service Adaptation Strategies Adaptation Strategies Adaptation Strategies Instrumentation System 3 6 r Monitor Mgr3 Management Monitor Monitor Mgr5 Mgr4 Diagnose r r Factory I r Diagnose Diagnose Service Manager Service Manager Service Manager Adaptation Strategies Adaptation Strategies Adaptation Strategies 4 A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 10
Demonstrator Ad-hoc service assembly tool Architecture transformation tool Software instrumentation tool A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 11
Conclusions & Future Work • Presented an architecture for conflict resolution and management for – Self-adaptive software – Supplied as a middleware service • Presented an example illustrating; – Propose programming model – Usage model • Further work – Resolution session control and management – Evaluation. A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 12
That’s the end – so I’m off ! A. Taleb-Bendiab, ICSE’02, Workshop on Architecture for Dependable Systems, Orlando, 20/09/99, Pages: 13
Recommend
More recommend
