Lorenz Kellerer

Introduction Problem Field

State of the Art The Paper Rainbow Framework

Case Studies

Implementation & Evaluation Reflection Contribution

Shortcomings Discussion

Introduction Problem Field

State of the Art The Paper Rainbow Framework

Case Studies

Implementation & Evaluation Reflection Contribution

Shortcomings Discussion

Implementation of last paper Framework to add self adaption to software

Even on legacy code

Can be reused on a broad spectrum of applications

Self Adaptation tightly coupled with application

Low rate of reusable code

Many different Platforms

Different mechanism

Different properties of interest

Introduction Problem Field

State of the Art The Paper Rainbow Framework

Case Studies

Implementation & Evaluation Reflection Contribution

Shortcomings Discussion

Based on components & connectors

Stores model of program and checks against constraints

2 main components:

Adaption infrastructure

▪ See next slides

Adaption knowledge

▪ Architecture dependent

Architecture independent System

▪ Sends out probes to assess structure of program ▪ Resource discovery ▪ Effectors carry out adaptation

Architecture ▪ Aggregate info from probes ▪ Store in Model ▪ Constraint evaluator checks model ▪ Adaption Engine decides course of action

Translation ▪ Closes gap of abstraction ▪ Map of common properties

Represented by entities

Component & Connectors

Constraints

▪ Guarantee correctness

Properties

▪ E.g. Load-time, RAM-Usage

Analysis

▪ Ways to analyze Program

▪ E.g. Performance analysis of queuing

Special entities Adaption operators

▪ Alter system configuration

▪ E.g. Add/Remove Services

Adaption strategies ▪ Resolve undesirable state

▪ E.g. Over memory budget → remove most expense, non-vital service

Based on system concerns May reduce reusability

Introduction Problem Field

State of the Art The Paper Rainbow Framework

Case Studies

Implementation & Evaluation Reflection Contribution

Shortcomings Discussion

2 Case studies

Web based client/server model

▪ Client queries Server cluster → stored in cluster queue

▪ 2 Adaptations

▪ Add server to cluster → if server load too high

▪ Client changes cluster → if bandwidth too low

Videoconferencing System

▪ Different Protocols communicate via servers

▪ 2 Adaptations

▪ Handheld user changes proxy → if connection bad

▪ Netmeeting client moves to cheaper relay → if only one user left

System layer infrastructure

Effectors: couldn’t be reused, no shared components

Probes: Load & Bandwidth reused

Resource discovery: reused

Architecture layer infrastructure

Gauges: same information needed → reused

Model manager, constraint evaluator & adaption engine reused

Translation infrastructure

Maps couldn’t be reused

But enabled reuse on higher levels

System specific adaption knowledge

Not reused

Introduction Problem Field

State of the Art The Paper Rainbow Framework

Case Studies

Implementation & Evaluation Reflection Contribution

Shortcomings Discussion

System Layer Uses various libraries to implement sensors

Architecture Layer Java Probes aggregate info & update model Translation uses common map

102k LoC 84k Architecture 11k System 4k Translation 1.8k non reusable

Based on Client/Server case study Self repair shows significant improvement

But takes time to react

Best on:

System wide scale

Long-term system behaviour trends

System provides hooks

Very likely with new software

Wrappers for legacy code

Requires good gauges to work

3rd party developers can provide that

Measuring & adaption done centrally

Only one instance of Rainbow running

Future work

Introduction Problem Field

State of the Art The Paper Rainbow Framework

Case Studies

Implementation & Evaluation Reflection Contribution

Shortcomings Discussion

Practical Implementation

Framework can be used by everyone

Proof that it works

Problem Domain:

Self Adaptive Software

Practical Solution:

Framework to be used by developers

Comprehensive evaluation

Only basic evaluation of a single use case

Motivation?

Provide Framework to simplify implementing self adaptation

Only two very similar test cases

More different Programs reduce reusability greatly

Performance only tested with one very specific test case

Pseudo code could have been left out

Whole functionality explained in 3 lines of text

Feels like padding

Good graph quality Question if all claims of reusability are true Interesting field of research

Introduction Problem Field

State of the Art The Paper Rainbow Framework

Case Studies

Implementation & Evaluation Reflection Contribution

Shortcomings Discussion

Java good idea, if overhead should be kept low?

Especially when used in conjunction with a c/c++ application

Sacrifice performance for portability?

Specific solutions for wildly different platforms