Dynamic Adaptation of NonFunctional Concerns

1
Dynamic Adaptation of Non-Functional Concerns

• Pierre-Charles David
• Thomas Ledoux
• Ecole des Mines de Nantes

2
Outline

• Motivation
• General Approach
• Our Proposition
• Base Program and Join-Points
• Non-Functional Aspects
• Adaptive Weaving Specification
• Dynamic Pointcut Definition
• Context-Aware Weaving
• Conclusion and Perspectives

3
Motivation

• Software has to deal with an increasing diversity
  and complexity of execution environment
• a wide spectrum of hardware platform
• each with dynamically varying resources
• In some cases, software evolution may need to be
  dynamic, with changes being performed on running
  systems
• Software must be able to adapt their behavior to
  fit dynamically the evolving environment

4
Dynamic Adaptability and Execution Environment

• A few examples
• Network
• sécuriser les communications quand la
  confidentialité est nécessaire (Intranet vers
  Internet)
• répartir les charges si un serveur ne peut
  répondre rapidement aux requêtes
• Bandwidth
• instaurer un mécanisme de cache si risque de
  perte de la bande passante
• dégrader un flux vidéo si la bande passante
  devient faible
• PDA
• adaptation de l'interface graphique
• compression automatique des données

5
General Approach

• We consider adaptations relative to the execution
  contexts evolutions
• Distinguish functional code ...
• does not depend on this context
• pure business logic
• e.g. e-commerce application
• from non-functional code
• depends on the context
• code whose sole purpose is to make sure the
  functional code performs correctly and
  efficiently in its environment
• e.g. persistence and distribution QoS

6
A Promising Approach

• Separation of concerns allows to cleanly
  encapsulate functional and non-functional
  concerns
• Aspect-Oriented Programming (AOP) provides
  support to combine the different concerns
• Composition is done by a weaver Kic97
• a language processor that
• accepts two kinds of code as input
• produces woven output code (i.e. the final
  program)

7
Our Proposition

• Make the weaver aware of the execution
  environment
• it can adapt the weaving to the evolutions of the
  environment
• software is always adapted to its environment
• Dynamic adaptation of non-functional concerns
  using adaptive weaving

8
Aspect-Oriented Programming

• An AOP system (AspectJ) consists in
• a base program
• self-contained
• contains join-points
• aspect programs
• defines pointcuts as sets of join-points
• attaches advices to these pointcuts
• coordinated by a weaver

9
Applying AOP to our decomposition

• Functional code ? Base program
• Non-Functional code ? Advices
• Adaptation Policies ? Weaving Specification
• Originality weaving specifications are
• reified, externalized
• context-aware
• The weaving can be adapted to changes in the
  execution context

Aspects
10
Base Program Join-Points

• Programmers write standard Java
• Special compiler adds a wrapper to functional
  objects Container
• Objects execution controlled by Container
• intercepts method calls
• exposes a join-point
• accepts dynamic association of advices

11
Non-Functional Aspects

• Non-Functional code implemented by wrapper
  objects
• act as generic advices
• Dynamically associated to Containers
• Attach/detach/reconfigure
• Container composes (sequentially) advices on
  methods interceptions

12
Adaptive Weaving Specification

• Adaptation Policies
• encapsulate all the weaving instructions, from
  the identification of pointcuts in the base
  program to their dynamic associations with
  non-functional aspects
• two kinds of policies which are to be used
  together to form a complete weaving specification

13
Dynamic Pointcut Definition

• Pointcuts
• by definition a set of join-points
• in our system set of methods receptions on a
  single functional object (around() execution
  (public .(..)) using AspectJs notation for
  pointcuts)
• a group of functional objects
• Functional objects have dynamic attributes
• some predefined className
• others reflecting their fields balance
• Groups defined in intention
• by a predicate over attributes
• dynamically updated

14
Application Policies

• Domain Specific Language (DSL) to
• specify groups/pointcuts
• bind adaptive non-functional aspect programs
• Syntax inspired by Lisp (simple flexible)

(def-group low-accounts parent all select
(and ( (attr className) Account))
(lt (attr balance) 300)) bind (logging))
15
Context-Awareness

• Non-Functional aspects depend on the execution
  environment
• Simple monitoring framework
• reifies the environment as a tree of resources
• resources described by dynamic attributes
• Adaptation rules env. condition ? action
• action require a specific aspect implementation

16
System Policies

• DSL to define groups of adaptation rules
• implements context-aware aspects

(def-policy logging (when (gt (attr
/host/storage.free-space_kb) 5000)
(ensure-attached logging.file ((format .
xml)))) (when (and (lt (attr
/host/storage.free-space_kb) 5000) (gt (attr
/host/network.free-bandwidth_kbs) 10))
(ensure-attached logging.network
((format . text)))))
17
Putting it all together

• At startup, our system
• loads policies
• sets up the monitoring framework
• starts listening to events
• Object creation or attributes change
• object moves in the most specific group
• Environment change
• adaptation rules re-evaluated and (de)activated
• At each moment, objects in group are weaved with
  all the active rules bound to the group

18
Conclusion

• Uses AOP paradigm
• base program functional code
• aspects non-functional services
• Weaving specification
• externalized using DSLs
• dynamic, context-aware
• Non-functional services always adapted to the
  state of the execution context

19
Perspectives

• Unanticipated software evolution
• Enable dynamic management of policies
• loading, unloading
• requires formalization (conflict detection)
• Work on reconfiguration operations
• safety guarantees, aspects composition
• Distributed behavior
• global consistency
• cooperation for global adaptation

20
Example Scenario

• Domain bank application
• Service monitoring of low accounts
• identify the corresponding Account instances
• log all activities of these accounts
• Implementation adaptation
• if possible, store on local disk in XML (easy to
  analyze)
• otherwise try on remote disk (but dont use too
  much bandwidth)