Architecturebased Selfadaptation

1
Architecture-based Self-adaptation

• David Garlan, Bradley Schmerl, Shang-Wen Cheng
• Carnegie Mellon University
• IBM 3rd Proactive ProblemPrediction Conference
• April 27, 2005

2
Motivating University Grade System

• Students using university web
• University aims to provide timely and ubiquitous
  access
• One student tries to hack in and change his
  grades
• Possible (escalating) responses
• Turn on auditing
• Switch authentication scheme
• Sandboxing
• Move grades data
• Close off connections
• Partition network
• Turn off services

3
Many Things Can Go Wrong

• Resource variability
• Changing environments
• Shifting user needs
• System faults

Application or network connection fails
University Grade Sys
Server load changes
Wireless device moves into a different network
User attempts foul-play
The system should dynamically adapt to these
problems.
4
Traditional, Internal Mechanisms

• Limitations
• Detection limited to localized view of system
• Outcome difficult to reason about
• Costly or infeasible to modify existing system
• Difficult to reuse logic for new system

• Exception handling
• Network time-outs
• Signal and interrupt
• Memory management

Data formatting in DB causes exception
Network failure causes time-outs
Video Conferencing
One application failure causes sig-HUP on the
socket of another
Garbage collection
5
External Adaptation
Model Adaptation mechanism
Architectural model Adaptation mechanism
monitor
adapt

• Global system perspective
• Important system-level behaviors and properties
• Explicit system integrity constraints
• Proven trade-off analysis techniques

University Grade Sys
Architecture-based self-adaptation
6
Desiderata for Solution

• Ideally, wed like a solution that
• enables software engineers
• to use architectural models
• to adapt existing systems
• Key Challenge One size does not fit all
• Solution should
• apply to many architecture and implementation
  styles
• general
• facilitate adding self-adaptation capabilities to
  software systems
• cost-effective
• support run-time trade-off between multiple
  adaptation goals
• composable

A family of systems with common element
types (e.g., client-server, pipe-filter)
Effort to add self-adaptation is small, e.g., one
person within days or weeks
Choice among competing goals based on stakeholder
preference
7
Outline

• Motivation
• Approach
• Preliminary Work
• Demo
• Discussion of Challenges

8
Our Rainbow Approach
Architecture Layer
Gauges
Effector mechanisms
Translation Infrastructure
Monitoring mechanisms
System API
9
Our Rainbow Approach (2)
Arch Evaluator
Adaptation Engine
Model Manager
Adaptation Executor
Translation Infrastructure
10
Rainbow as a Tailorable Framework

• General framework with
• Reusable infrastructure tailorable mechanisms
• Specialized to targeted
• system adaptation goals
• Main components
• Monitoring mechanisms
• Model manager
• Architectural evaluator
• Adaptation engine
• Effector mechanisms

• Whats tailored
• Properties
• Vocabulary of model
• Architectural constraints
• Strategies tactics
• Operators

11
Rainbow Illustrated
Arch Evaluator
Adaptation Engine
Model Manager
Adaptation Executor
Translation Infrastructure
Translator
12
Rainbow Illustrated Intrusion Detection
Rainbow Mechanisms
False! Find the right tactic
True? intrusion_prob Client2.isolate() /Grades.audit()
Model Manager
Client2.intrusion_prob 75
Translator
Grade change
Change link / Add Auditing
13
Preliminary Work Shows Promise

• Rainbow prototype
• Integrated mechanisms and tested control cycle
• Demonstrated usefulness for specific adaptation
  scenarios
• Three case studies
• Three styles of system
• Client-server, service-coalition, data repository
• Three kinds of adaptation goals
• Performance security cost
• Adaptation language under development

14
Demo

• Next up
• Walk through a few case studies
• Demonstrate applicability to many architecture
  styles

15
Case Study 1 Client-Server System

• System style Client-server
• Adaptation goal investigated
• Performance (latency)

• Experiment demonstrated
• Adaptation cycle is feasible
• Timing is reasonable

Adaptation strategies to counter perfor-mance
problems
Strategy fixLatency
Constraints on performance properties
Invariant responseTime
Vocabulary of client-server elements and
performance properties
Client-server architecture change operators
ClientT, ServerT,ServerGrpT, LinkT responseTime,
load
ServerGroupT.addServer() ClientT.move()
Mapping of elements and operators to system-level
actions
ServerT ? ServerClass, etc.
System properties to monitor
Link latency, link bandwidth, server load
16
Case Study 2 Video Conferencing

• System style Service-coalition
• Adaptation goals investigated
• Performance cost

• Case study showed
• 90 of framework reuse
• Need for principled coordination

Strategy fixHHBandwidth, fixGatewayCost
Invariant HH.availBandwidth minHHBandwidth
VicT, NetMeetingT, HandheldT, GatewayT,
ConnT cost, load, bandwidth
HandheldT.move() NetMeetingT.move()
GatewayT ? sysGateway, etc.
Gateway/proxy cost and load, link bandwidth
17
Case Study 3 University Grade System

• Composite system style
• Client-server data repository

• Adaptation goals investigated
• Performance security

Strategy counterIntrusion, counterDoS
Invariant intrusionProb
FirewallT, DbT, ServerT, SSHT intrusion, load
GradeServerT.addService(), DbT.audit()
DbT ? MySQL DB, etc.
intrusion behavior patterns specific IDS
18
Some Research Problems

• Architectural recovery at run time.
• Efficient, scalable constraint evaluation
• Environment modeling and scoping
• Handling multiple models and dimensions of
  concern
• Reasoning about the correctness of a repair
  strategy
• Timing issues
• Non-deterministic arrival of system observations
• Change latencies
• Avoiding thrashing
• Adapting the adaptation strategies

19
Status of Rainbow

• What we have
• Model representation
• Acme AcmeLib architectural description
  language and the API
• Armani architectural constraint language
  evaluator
• Monitoring mechanisms
• Gauge and probe infrastructure
• Basic toolbox of gauges and probes
• Latency, bandwidth, load, timing, etc.
• Translation infrastructure
• DiscoTect architecture model recovery
• Design of infrastructure
• What were working on
• Adaptation language and engine
• Model support for the system environment
• Translation infrastructure implementation
• More case studies!

20
The END
Conclusion
Architecture-based Self-adaptation

• Presentation synopsis
• Problem
• Systems need to dynamically adapt
• Use architectural model to monitor and adapt
  system
• Proposed solution
• The reusable, tailorable Rainbow framework
• Applicable to many styles, multiple adaptation
  goals
• Challenges to tackle
• Adaptation representation, modeling, coordination
• Questions?

Shang-Wen Cheng