1. Rahul Raheja, Shang-Wen Cheng, David Garlan, Bradley Schmerl Carnegie Mellon University 1

2. Architecture-based Self-adaptation Motivating example: Cost vs. security Changes required to enable preemption  Selection  Granularity  Interference Experimentation & Results Discussion  Decentralized self-adaptation 2

3. Target System Effectors Probes Resource Discovery SYSTEM API Translation Infrastructure Translation Infrastructure Model Act Monitor Decide Architecture Layer System Layer Gauges 3

4. Effectors Probes Resource Discovery SYSTEM API Translation Infrastructure Translation Infrastructure Model Act Monitor Decide Architecture Layer System Layer Gauges Fixing Cost Security violation ! Blocked 4 P P server Client

5. Adaptations only considered if no other adaptations in progress Timeliness of adaptations not considered  Timeliness => Effectiveness of adaptation diminishes over time Preemption  When a new problem arises  Pause current adaptation  Check to see if new condition should be dealt with first  Execute it (if necessary)  Resume paused adaptation 5

6. To introduce preemption, need to consider:  Selection: How to decide whether an adaptation should be interrupted for more “important” adaptation  Granularity: What are the possible points at which adaptations can be interrupted  Interference: How to handle cases where strategies may change the same parts of the system 6

7. Formal notion of timeliness  Capture change in effectiveness of adaptations over time  Time Utility Curve (TUC) Consideration of timeliness in adaptation selection  Schedule adaptations in an order that maximizes predicted system utility (PSU)  Timeliness means that order matters! 7 Completion Time Utility Completion Time Utility

8. 8 A S1 A F2 A C1 A F2 A C1 Schedule 1 Schedule 2 90%70%80% 90% 70% 0% 70%80%90% 70% 25% 0% A S1 - Security A F2 - Fidelity A C1 - Cost Improvement Timely Improvement Improvement Timely Improvement TUCs Rainbow strategy selection is more involved than this. See paper A S1

9. Adaptations usually multiple steps Where to pause? Criteria:  Maximize timeliness  Keep system integrity Each adaptive system will have its own points  Rainbow has three levels of granularity:  Strategy, Tactic, Operation  We chose Tactic  Guarantees and checks of system consistency already specified  Allows a level of interleaving 9

10. With preemption comes potential for interference  New adaptation could change same parts of system as paused  Resuming paused adaptation means system now in a different state Architectural locks:  Executing adaptation “locks” part of the architecture  Adaptations must be queried for part of the system they will change  If there is overlap, discard that strategy On-going work 10

11. Client-server system balancing between cost and security Two strategies:  reduceOverallCost: discharges excessive servers  increaseSecurity: secures a server against intrusion Experiment causes security violation detection to occur when reduceOverallCost is running We execute experiment in two cases:  Original Rainbow, where security must wait  Preemption, where cost fix will be preempted 11

12. 12

13. Scalability  Calculation of permutations for ordering factorially complex  Are there better ways to reduce permutations considered?  How many potential simultaneous adaptations?  How many potential schedules? Interference granularity  Is architecture locking the right level? True concurrency  Currently, only need non-interference between paused and executing strategies  Can we generalize this for true concurrency? 13

14. Rainbow is intentionally centralized to permit system- wide (non-local) analyses For distribution:  Could use coordinated self-management of the type we discussed in An Architecture for Coordinating Multiple Self-Management Systems. In Proceedings of the 4th Working IEEE/IFIP Conference on Software Architectures (WICSA4)  Require three elements:  Shared target system access facilities for consistent views  Model exchange and translation facilities  Coordinated decision making facilities Preemption:  Distributed real-time scheduling theories for distributed scheduling  Distributing control could be advantageous if boundaries can guarantee non-interference 14

15. Time-critical adaptations need prompt scheduling  Preemption of any executing strategies  Requires consideration of selection, granularity, interference Shown usefulness in multi-objective environments Rainbow now allows plugins for  Scheduling algorithm  Conflict detection  Prioritization scheme  Allows experimentation with other techniques 15

16. Architecture-based self-adaptation involves  Adapting a system to maximize system utility  Choosing adaptations in the presence of multiple quality dimensions  Use of an architectural model to reason about global properties of the system Time-critical adaptations not considered  Adaptations block others until they finish  Effectiveness of adaptation diminishes if not completed in a timely manner  Hinders overall system utility Introduce preemption  Increases overall system utility  What is required to introduce this in architecture-based self- adaptation 16

17. 17

18. 18 strategy ImproveOverallFidelity [ styleApplies && lowFi ] { t0: (lowFi) -> raiseFidelity(2, 100) @[800 /*ms*/] { t1: (!lowFi) -> done; t2: (lowRespTime && lowFi) -> do[1] t0; t3: (default) -> TNULL; } Condition of Applicability Tactics tactic lowerFidelity (int step, float fracReq) { condition { exists c : T.ClientT in M.components | c.experRespTime > M.MAX_RESPTIME; exists s : T.ServerT in M.components | s.fidelity > step; } action { set servers = { select s : T.ServerT in M.components | s.fidelity > step }; for (T.ServerT s : servers) { S.setFidelity(s, s.fidelity - step); } … Operator Strategy Tactic Guard