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. Andrea Zisman Background Motivation MADap Framework Overview Patterns Adaptation Process Initial Evaluation Conclusions and Future Work Outline

3. Andrea Zisman 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. Andrea Zisman 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

5. Andrea Zisman 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. Andrea Zisman 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. Andrea Zisman 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. Andrea Zisman User Context

9. Andrea Zisman 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. Andrea Zisman Event Calculus (Predicates) PredicateMeaning Happens (event, t, R(t1,t2))The occurrence of an event, at sometime t, where t is between t1 and t2 Initiates (event, fluent, t)The initialization of a fluent; which means a fluent starts to hold after an event occurs at a time t Initially P (fluent)The fluent holds (is valid) from time 0 Initially N (fluent)The fluent does not hold from time 0 HoldsAt (fluent, t)The fluent holds (is valid) at a time t Clipped (t1, fluent, t2)The fluent is terminated between the time interval specified by t1 and t2 Declipped (t1, fluent, t2)The fluent is initiated between the time interval specified by t1 and t2 Terminates (event, fluent, t) The fluent ceases to hold after an event occurs at a time t Plus: logical, relational, implication operators & axioms

11. Andrea Zisman MADap Architecture

12. Andrea Zisman 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. Andrea Zisman Examples: Pattern Role 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) 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)

14. Andrea Zisman Pattern Cognition 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) 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)

15. Andrea Zisman 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. Andrea Zisman 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. Andrea Zisman 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. Andrea Zisman CasesResults 1: Empty repository29 rules with assumptions were created: 8 for context type role; 6 for context type need; 4 for context type skill; 8 for context type cognition; 3 for context type preference 2: Repository with 100 unrelated rules29 rules/assumptions were created (Case 1) 3: Repository with 29 related rulesFor each different context type relevant rules were identified 4: Repository with 29 related and 100 unrelated rules For each different context type relevant rules were identified (as in Case 3) 5: Repository with 100 unrelated and 27 related rules, and 5 rules that match invariant parts for each context type For each context type relevant rules from the 27 rules were identified, two rules were created, and 5 rules matching invariant parts were identified and checked for maintenance or removal from repository

19. Andrea Zisman 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