1 / 19

Identifying, Modifying, Creating, and Removing Monitor Rules for SOC

Identifying, Modifying, Creating, and Removing Monitor Rules for SOC. Ricardo Contreras Andrea Zisman ricardo.contreras.1@soi.city.ac.uk A.Zisman@soi.city.ac.uk Software Engineering Group School of Informatics City University London UK.

leslie-cooley
Download Presentation

Identifying, Modifying, Creating, and Removing Monitor Rules for SOC

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. Identifying, Modifying, Creating, and Removing Monitor Rules for SOC Ricardo Contreras Andrea Zisman ricardo.contreras.1@soi.city.ac.uk A.Zisman@soi.city.ac.uk Software Engineering Group School of Informatics City University London UK

  2. Outline • Background • Motivation • MADap Framework Overview • Patterns • Adaptation Process • Initial Evaluation • Conclusions and Future Work

  3. Background • Monitoring of service-based systems • Collecting information about the execution of SBS and verifying if the system operates correctly based on system’s properties (monitor rules) • SBS monitoring supports • adaptation, repair, and evolution of SBS • discovery and replacement of services • notification of SLA, business rules, and KPI violations • optimization of resource allocation • Existing monitoring approached are based on: • Type of information being monitored (what) • Purpose of monitoring activity (why) • Used techniques for monitoring (how) • Intrusive: instrumentation of the SBS or its services • Non-intrusive: use special components to capture runtime service information

  4. Motivation • Monitoring approaches • assume monitor rules are pre-defined and known in advance • Monitor needs to support changes in • SBS and services used by SBS • Types of interactions of users with the system • Context characteristics of the users interacting with the system Monitor Adaptation

  5. Motivation (Example) Cultural event service-based system (CE_SBS) S1: What’s going on (per city) S2: Ticket search and selection S3: Payment S4: Performance scheduling S5: Resource search and allocation S6: Catering S7: Performance review …

  6. Framework Overview • Pattern-based HCI-aware monitor adaptation framework (MADap) - changes in monitor rules due to user’s interaction and different types of user context • Adaptation activities: identification, modification, creation, removal • Rule patterns for different types of user context: role, skills, needs, preferences, cognition, time, location, environment • Rules concerned with execution parts of SBS for a user context type • User models for representing information about users • Patterns and monitor rules represented in event-calculus (EC)

  7. Context Types • Direct: information about the characteristics of users • Role: the social behavior of an individual within the domain of a SBS (e.g., occupation, access type, privilege) • Skill: the level of expertise of an individual with respect to a SBS (e.g., level of expertise, years of experience) • Preference: an individual’s choice over pre-established alternatives of computational resources of a SBS • Cognition: individual’s characteristics associated with the process of thought (the way that individuals think, feel or react; e.g., attention level, comprehensive ability) • Need: an individual’s requirement or desire from a SBS • Related: information that may influence data about a user • Time: the moment an individual interacts with a SBS • Location: the place where an individual interacts with a SBS • Environment: the environment where a SBS is used

  8. User Context

  9. Event Calculus • Why? It supports • rule representation as first order logic providing expressiveness for large range of applications • specification of quantitative temporal constraints and relationships • distinction between events and states • definition of influences between events and states • It uses events and fluents to represent system’s behavior • Event: action occurring at a specific time and may change the state of a system • Fluent: condition of a system state that may be affected by events

  10. Event Calculus (Predicates) Plus: logical, relational, implication operators & axioms

  11. MADap Architecture

  12. Patterns • Parts: • Monitor rule: properties of a systems that need to be monitored • Assumptions: formulae to identify system’s state information • Event types • Operation request/response: prefix ic/ir • Initial/last event: ic_initial/ic_last • User interaction: ic/ir + user_op

  13. Examples: Pattern Role Monitor Rule: Happens (ic_initialeventE, t1, R(t1,t1))  Happens (ic_operX, t2, R(t1,tn)) Assumption: Happens(ic_operX, t, R(t, t))  Initiates (ic_operX, fluent, t) R1: Happens (ic_start_CE, t1, R(t1,t1))  Happens (ic_shows, t2, R(t1,t1+2500)) Ass: Happens(ic_shows, t1, R(t1, t1))  Initiates (ic_shows, list_shows, t1) R2: Happens (ic_start_CE, t1, R(t1,t1))  Happens (ic_perfschedule, t2, R(t1,t1+3000)) Ass: Happens(ic_perfschedule, t1, R(t1, t1))  Initiates (ic_perfschedule, list_perfschedule, t1)

  14. Pattern Cognition Monitor Rule: Happens (ic_OperX_User_op, t1, R(t1, t1))  Happens (ir_OperX_User_op, t2, R(t1, t1+(response time for OperX))) Assumption: Happens(ic_OperX, t1, R(t1, t1))  Initiates (ic_OperX, fluent, t1) • R3: • Happens (ic_userIdentification, t1, R(t1,t1))  • Happens (ir_userIdentification, t2, R(t1,t1+90)) • Assumption: • Happens(ic_userIdentification, t, R(t, t))  • Initiates (ic_userIdentification, userIdentification, t)

  15. Adaptation Process Identify semi-instantiated pattern; Search for rules that match semi-instantiated pattern (SI); C1: repository has rules Set(R) that fully match SI pattern /*verify if time values in rules are consistent */ For every rule R in Set(R){ if time values in rules are consistent {rules maintained in the repository;} if time values in rules are not consistent {rules are modified with new time values based on SLAs/historical execution data;} }

  16. Adaptation Process C2: repository has rules Set(R) that only match invariant part of SI pattern create new rule by instantiating time values for SI pattern; add new rule in repository; /*verification of the validity of rules*/ For every rule R in Set(R){ if there is valid path in SBS specification that uses R {time values for R are checked and adjusted if necessary;} if there is no valid path in SBS specification that uses R {R is removed from repository;}} C3: repository does not have rules that match SI pattern create new rule by instantiating time values for SI pattern; add new rule in repository;

  17. Implementation and (Initial) Evaluation • Prototype tool implemented • Evaluation • CE-SBS with seven services • Demonstration of four adaptation cases: identification, modification, creation, removal • Context types: role, skills, need, preference, cognition • Five different cases

  18. Conclusions and Future Work • Conclusions: • Framework for identifying, modifying, creating, and removing monitor rules expressed in EC • HCI-aware monitor adaptation • Use of rule patterns • Current/Future Work: • Creation of more patterns • Evaluation: • Performance • Use of adapted rules • Extension of the work to support: • Adaptation of assumptions • Adaptation due to changes of several context types • Patterns/Rules specified in other formalisms

More Related