ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures

ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures

SAC’14 - DADS 28.3.2014

Philippe Collet Robert B. FranceColorado State University

Computer Science Department USA

Université Nice Sophia Antipolis I3S - CNRS UMR 7271

France

University Lille 1 / LIFLINRIA Lille

France

Filip Křikava

28.3.2014, SAC’14 - DADSACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures

CONTEXT

Jeff Kephart - Autonomic Computing: The First Decade, ICAC’11 keynote

Electronic Retailer - Application Diagram

• Ever growing complexity of computing systems • Taming this complexity by skilled IT professionals does not scale • New operation modes are needed


TOWARDS SELF-ADAPTIVE SOFTWARE SYSTEMS

Monitoring Reconfiguration

Decision Making

sensors effectors

Target System

events actions

measures decisions

Feedback Control Loop (FCL)

Systems that adjust themselves in accordance with some higher-level goals

• response time • utilization • scheduling

• concurrency policies


Engineering of self-adaptive software systems is a challenge

Designing an adaptation engine

Controller Target System

Transducer

+ -

� =mX

i=1

1

d=

m

d

⇥(N) = �µ =

md

µ

d =m

�(N)µ

CHALLENGES





Transducer

+ -

� =mX

i=1

1

d=

m

d

⇥(N) = �µ =

md

µ

d =m

�(N)µ

CHALLENGES

Integrating an adaptation engine into a target system

API

LOGS

CONFIGURATIONS

COMMANDS

AOP

PROFILER

• Consistent monitoring across all sensors • Coordination of adaptation action





Transducer

+ -

� =mX

i=1

1

d=

m

d

⇥(N) = �µ =

md

µ

d =m

�(N)µ

CHALLENGES


API

LOGS

CONFIGURATIONS

COMMANDS

AOP

PROFILER

• Consistent monitoring across all sensors • Coordination of adaptation action



Adaptation Engine Target System


Transducer

+ -

� =mX

i=1

1

d=

m

d

⇥(N) = �µ =

md

µ

d =m

�(N)µ

API

LOGS

CONFIGURATIONS

COMMANDS

AOP

PROFILER

• Adhoc Implementations • Extensive handcrafting of non-trivial code • Cumbersome and error-prone • Accidental complexities

CHALLENGES



Adaptation Engine Target System


Transducer

+ -

� =mX

i=1

1

d=

m

d

⇥(N) = �µ =

md

µ

d =m

�(N)µ

API

LOGS

CONFIGURATIONS

COMMANDS

AOP

PROFILER

• Reusing and adapting existing work • Often target specific types of adaptation problems [Bertran’12] • Require the use of certain adaptation mechanism [Garlan’04] • Applicable to single domain [Rouvoy’08] or technology [Asadollahi’09] • Do not support remoting or complex control schemes [Adamczyk’08, Gorton’06] • Limiting their applicability

CHALLENGES


Derived requirements for integrating self-adaptation into software systems

Generality

• Domain-agnostic • Technology-agnostic

• Explicit FCLs, their process and interactions • Verification support

Visibility

• Reusable FCL parts across adaptation scenarios

Reusability

• Remote distribution of FCL

Distribution

• Composition • Reflection

Complex control

• Prototyping • Automating

Tooling

REQUIREMENTS



Decision Making

sensors effectors

Target System

events actions

measures decisionsController Target System

Transducer

+ -

� =mX

i=1

1

d=

m

d

⇥(N) = �µ =

md

µ

d =m

�(N)µ

API

LOGS

CONFIGURATIONS

COMMANDS

AOP

PROFILER

Generality Visibility Reusability

Distribution Complex control

Tooling

CONTRIBUTIONS

Feedback Control Definition Language1

The ACTRESS Modeling Environment2

Approach facilitating systematic integration of self-adaptive mechanisms into software systems through feedback control loops.


FCDL: Feedback Control Definition Language1


FEEDBACK CONTROL DEFINITION LANGUAGE

1. Raise the level of abstraction

2. Fine-grained decomposition of FCL elements

3. Explicit interactions

4. Provide reflection and composition capabilities

5. Embed remoting

Monitoring Decision Making Reconfiguration

measures

events

decisions

actions

General Purpose Language (GPL)Generality

Visibility

Reusability

Distribution

Complex control


1. Raise the level of abstraction 2. Fine-grained decomposition of FCL elements 3. Explicit interactions 4. Provide reflection capabilities 5. Embed remoting

Domain-Specific Modeling





• Feedback Control Loop • Sequence of interconnected processes • Inputs x State -> Output • Reactive • Concurrent • Dynamic


Decision Making

sensors effectorsevents actions

measures decisions





• Feedback Control Loop • Sequence of interconnected processes • Inputs x State -> Output • Reactive • Concurrent • Dynamic


Decision Making


measures decisions

• The Actor Model • Message passing actor networks • Message x State -> Message(s) • Reactive • Concurrent • Dynamic • Scalable • Remoting through location

transparency

actor

actor

actor




Decision Making


measures decisions

Processor

in input

out output

Effector

in input

Sensor

out output

Target System

in input

Controller

in input

out output

Processor

out output

FEEDBACK CONTROL DEFINITION LANGUAGE - IN A NUTSHELL

Network of Adaptive Elements - actor-like entities



Decision Making


measures decisions

Processor

in input

out output

Effector

in input

Sensor

out output

Target System

in input

Controller

in input

out output

Processor

out output

in input

providedEffectorprovidedSensor

out output

FEEDBACK CONTROL DEFINITION LANGUAGE - IN A NUTSHELL

Network of Adaptive Elements - actor-like entities


Idea: service time = fixed overhead + data-size dependent overhead

Abdelzaher et al., 1999, 2002

QoS management control of web servers by content delivery adaptationGoal: maintain server load around some pre-set value

Prerequisite: preprocessed content (different quality and size)

ILLUSTRATION





/1/photo.jpg

/2/photo.jpg

/photo.jpgfull quality

degraded quality


ILLUSTRATION





/1/photo.jpg

/2/photo.jpg


degraded quality

normal load

overload


ILLUSTRATION




QoS management control of web servers by content delivery adaptation

...

serve fromtree #2

serve fromtree #1

Rejection Level

Minimum Content Full Content

Goal: maintain server load around some pre-set value

/1/photo.jpg

/2/photo.jpg


degraded quality

normal load

overload


ILLUSTRATION




QoS management control of web servers by content delivery adaptation

...

serve fromtree #2

serve fromtree #1

Rejection Level

Minimum Content Full Content

Goal: maintain server load around some pre-set value

/1/photo.jpg

/2/photo.jpg


degraded quality

normal load

overload


ILLUSTRATION

Distribution Complex control

Generality Visibility Reusability

Using FCDL


ILLUSTRATION

Compute severity of adaptation (G)

Compute the requests rate (R), bandwidth (W) and utilization (U)

Compute the number of requests (r) and size of responses (w)12

3


ILLUSTRATION

Compute the number of requests (r) and size of responses (w)1

accessLog: FileTailer

out lines

file=/var/log/apache2/access.log

access_log

active sensor FileTailer { push out port lines: String ! property file: String }

processor Accumulator { push in port input: long pull out port sum: long }

processor AccessLogParser { push in port lines: String push out port size: int push out port requests: int }

Generality

Visibility

Reusability

requestCounter: Accumulator

responseSizeCounter: Accumulator

in input

out sum out sum

in lines

out sizeout requests

accessLogParser: AccessLogParser


ILLUSTRATION

Generality

Visibility

Reusabilityaccess_log

active processor PeriodTrigger<T> { pull in port input: T push out port output: T ! property initialPeriod = 10.seconds }



scheduler: PeriodTrigger

loadMonitor: LoadMonitor

in input

out sum out sum

in requests in size

out utilization

in input

out output

initialPeriod=10s


in lines

out lines

file=/var/log/apache2/access_log



Compute the requests rate (R), bandwidth (W) and utilization (U)2


ILLUSTRATION

Generality

Visibility

Reusabilitycontent_tree

access_log

utilController: UtilizationController





in input

out sum out sum

in requests in size

out utilization

in input

out output

in utilization

out contentTreeinitialPeriod=10s

adaptor: ContentAdaptor

in contentTree


in lines

out lines




k=?U*=?

Compute severity of adaptation (G)3


ILLUSTRATION

GeneralityVisibilityReusability

composite ApacheQOS { ! feature accessLog = new FileTailer { file = “/var/log/apache2/access_log” } ! feature accessLogParser = new AccessLogParser feature requestCounter = new Accumulator feature responseSizeCounter = new Accumulator feature loadMonitor = new LoadMonitor feature scheduler = new PeriodTrigger<Double> feature utilController = new UtilizationController feature adaptor = new ContentAdaptor ! connect accessLog.lines to accessLogParser.lines connect accessLogParser.size to responseSizeCounter.input connect accessLogParser.requests to requestsCounter.input connect requestCounter.output to loadMonitor.requests connect responseSizeCounter.output to loadMonitor.size connect loadMonitor.utilization to scheduler.input connect scheduler.output to utilController.utilization connect utilController.contentTree to adaptor.contentTree }

Complete model of the first prototype

ApacheQOSutilController

: UtilizationController

in input





in input

out sum out sum

in requests in size

out utilization

in input

out output

in utilization

out contentTree

syst

em

laye

rco

ntro

l la

yer

initialPeriod=10s


in contentTree


in lines

out lines




k=?U*=?


COMPOSITION

Generality

Visibility

Reusability

Hierarchical organization of Adaptive Elements using composites

ApacheQOS utilController: UtilizationController

in input





in input

out sum out sum

in requests in size

out utilization

in input

out output

in utilization

out contentTree

out requests

out size

syst

em

laye

rco

ntro

l la

yer

composite name

initialPeriod=10s


out

size

in contentTree

out size

out

requ

ests out requests in contentTree

port promotion

in contentTree

ApacheWebServer

server: ApacheWebServer



in lines

out lines


k=?U*=?

composite ApacheWebServer { ! property accessLogFile: String feature accessLog = new FileTailer { file = accessLogFile } ! feature accessLogParser = new AccessLogParser feature adaptor = new ContentAdaptor connect accessLog.lines to accessLogParser.lines ! promote accessLogParser.size promote accessLogParser.requests promote adaptor.contentTree !}


ApacheQOS

control: QOSControl

in contentTree

apache: ApacheWebServer

in requests

in size

out requests

out size

out contentTree

cont

rol

laye

rsy

stem

la

yer

QOSControl


utilization: UtilizationMonitor

out contentTree


out utilizationin input out output

in utilization

out contentTreein requests in size

in requests in size

LighttpdQOS

control: QOSControl

in contentTree

lighttpd: LighttpdWebServer

in requests

in size

out requests

out size

out contentTree

cont

rol

laye

rsy

stem

la

yer

QOSControl


utilization: UtilizationMonitor

out contentTree


out utilizationin input out output

in utilization

out contentTreein requests in size

in requests in size

COMPOSITION

Generality

Visibility

Reusability


REMOTE DISTRIBUTION

Remote distribution of Adaptive Elements

remote-main remote-apache

network

ApacheQOS

in contentTree

in requests

in size

out requests

out size

out contentTree

Apache.apacheendpoint= akka.tcp://actress@remote-apache/user/Apache/apache

referenced feature

Apache

in contentTree

in requests

in size

out requests

out size

out contentTree

ApacheQOS.control

endpoint=akka.tcp://actress@remote-main/user/ApacheQOS/control


control: QOSControl

composite feature

// deployed at remote-apache composite Apache { feature apache = new ApacheWebServer { ... } feature control = ref ApacheQOS.control @ "akka://remote-main/user/ApacheQOS/control" } !// deployed at host remote-main composite ApacheQOS { feature control = new QOSControl { ... } feature apache = ref Apache.apache @ "akka://remote-apache/user/Apache/apache" // ... }

Distribution

Visibility


REFLECTION

Visibility

ApacheQOSco

ntro

l la

yer

sysLoad: SystemLoad

met

a-co

ntro

l la

yer

periodController: PeriodController

out output

in load out period

syst

em

laye

r

sysLoadTrigger: PeriodTrigger

in input

out output

in contentTree


in requests

in size

out requests

out size

out contentTreeQOSControl


in input out output

setPeriod

provided in setPeriod

... ...

provided effectorpromotion


control: QOSControl

active processor PeriodicTrigger<T> { pull in port input: T push out port output: T ! provided effector setPeriod: Long ! property initialPeriod = 10.seconds } !composite QOSControl { // ... promote scheduler.setPeriod // ... }

Complexcontrol


Visibility

Complexcontrol

ApacheQOS

cont

rol

laye

r

sysLoad: SystemLoad

met

a-co

ntro

l la

yer

out output

in load out period

syst

em

laye

r

in contentTree


in requests

in size

out requests

out size

out contentTreeQOSControl


in input out output

setPeriod


... ...

provided effectorpromotion


control: QOSControl

periodControl: AdaptiveMonitoring

REFLECTION - ADAPTIVE MONITORING

Reusability


INTERACTION CONTRACTS

in input

: Accumulator

out sum

• Activated on input push request • Activated on sum pull request



in input

: Accumulator

out sumin reset

out output

• Activated on input push request • Activated on reset push request • Activated on input / reset request • Activated on sum pull request • Activated on input push request always pushing data on output • Activated on reset push request always pushing data on output • ....



in input

: Accumulator

out sumin reset

out output

• Behavior not explicitly stated in the architecture - Black Box • Limits verification support • Limits code-generation support

When it receives data on its input port, it pushes to its output port the input value plus the sum of all the input values it has received since the last time the reset port was triggered, similarly, when pulled on the sum port, it returns the sum of all the input values since the last reset, and finally receiving any data on its reset port, sets the current accumulated value back to 0.

if (!input.isEmpty()) { value += input.get output.send(value) } else if (!reset.isEmpty()) { reset.get() value = 0 } else if (!sum.isEmpty()) { sum.send(value) } else { throw new IllegalStateException("Invalid execution") }



in input

: Accumulator

out sumin reset

out output

• Describe allowed interactions among components

Visibility

• Originally developed by Cassou et al. for SCC systems • Our extensions

• Elements with multiple output ports • Multiple port connections • Composites • Composite interaction contract inference algorithm • Optional contracts • Completion verification algorithm

processor Accumulator { push in port reset: int push in port input: long pull out port sum: long push out port output: long ! act onInput(input; ; output) act onSum(sum; ; ) act onReset(reset; ; ) }


The ACTRESS Modeling Environment2


Modeling

VerificationCode Generation

Tooling

• Reference implementation of FCDL based on Eclipse Modeling Framework • Facilitate the use of FCDL

THE ACTRESS MODELING ENVIRONMENT


ACTRESS - MODELING SUPPORT

controller UtilizationController { // ... ! // interaction contract act activate(utilization; ; contentTree) // beginning of Xbase implementation implementation xbase { var G = M ! // interaction contract act activate { // computes the error val E = targetUtilization - utilization // computes new extend of adaptation G = G + k * E ! // correct bounds if (G < 0) G = 0 if (G > M) G = M // returns the result G } }

• xFCDL (Extended FCDL) • Textual DSL for authoring FCDL models • Additionally supports

• Modularity • Java interoperability • Implementation specification

using Xbase • Eclipse IDE support


in utilization

out contentTree

k=?U*=?


ACTRESS - CODE GENERATION SUPPORT

accessLogParser accessLog adaptor

apache control

requestCounter

responseSizeCounter

loadMonitor

utilization

scheduler utilController

ApacheQOS

ACTRESS Runtime

actor

actor with event listener

compositeactor

containment

messagepassing

ApacheQOS utilController: UtilizationController

in input





in input

out sum out sum

in requests in size

out utilization

in input

out output

in utilization

out contentTree

out requests

out size

initialPeriod=10s

in contentTree

server: ApacheWebServer

k=?U*=?

Code generator

Model-to-Texttransformation

ACTRESS Domain

Framework

FCDL Model

Executable System

• Xbase compiled to Java • Skeleton implementation


ACTRESS - CODE GENERATION SUPPORT - SKELETON IMPLEMENTATION

@SuppressWarnings("all") public class UtilizationControllerAct extends AdaptiveElementAct { ! // ... ! protected double activate(final double utilization) { // TODO: compute and output value for contentTree port } ! // ... !}


in utilization

out contentTree

k=?U*=?

• Prescriptive • Restrictive

Visibility


ACTRESS - VERIFICATION SUPPORT • Architecture • Consistency • Determinacy • Completeness

• Interaction contracts verification

@OCL(invDifferentSource="self.ports->select(p | p.name = 'size' || p.name = 'requests') // select ports ->collect(p | p.connections) // select their connects->collect(p | p.parent) // select owning instances->asSet()->size() == 2 // there must be two different ones")processor LoadMonitor {

• User-defined structural constraints • xFCDL OCL annotations

• User temporal constraints • FCDL to PROMELA transformation

• SPIN model checker

⇤ ( accessLogParseractivate ! (⌃ utilControlleractivate))

FCDL Verification

• Model well-formedness • Data-type compatibility • Port connections • Required properties • and others

• Meta-model constraints


Assessment and Summary3


ASSESSMENT

• Illustration case study - running example • Additional case studies in the area of HTC computing

• HTCondor Local Job Submission Overload Control • HTCondor Distributed Job Submission Overload Control

UHPRWH6WDWV &HQWUDO6WDWVFHQWUDO6WDWV

N∗ = 1000, Nc = 5000, p = 5, ρ0 = 10

/RDG&RQWUROOHU

1

2

1 2

/RFDO&RQWURO

KWWS��ZZZZ�JULG��IU

Overall implementation effort

Separation of concerns


ASSESSMENT

Generality Visibility

Reusability• Reused elements across scenarios

• Potentially any self-* property • Abstraction is close to block diagrams from

control theory • Control complex schemes through reflection • FCDL is technology agnostic • xFCDL with Xbase depends on Java • ACTRESS runtime depends on Java

Distribution

Complex control

• Case Study 2 deployed on 10 Grid5000 hosts

• All case studies use hierarchical control • Eclipse based modeling environment • Model to code synthesis

Tooling

• Explicit FCLs • Explicit AE • Explicit AE interactions • Known concepts such as ports and composites • Higher-level of abstraction using control theory

concepts


ASSESSMENT

Generality Visibility

Reusability• Reused elements across scenarios

• Potentially any self-* property • Abstraction is close to block diagrams from

control theory • Control complex schemes through reflection • FCDL is technology agnostic • xFCDL with Xbase depends on Java • ACTRESS runtime depends on Java

Distribution

Complex control

• Case Study 2 deployed on 10 Grid5000 hosts

• All case studies use hierarchical control • Eclipse based modeling environment • Model to code synthesis

Tooling

• Explicit FCLs • Explicit AE • Explicit AE interactions • Known concepts such as ports and composites • Higher-level of abstraction using control theory

concepts

• Performance1 • ACTRESS runtime accounts for ~1.5MB • AE accounts for 400 bytes • 5000 messages accounts for 5% of CPU utilization

1MacBook Pro 2.53 Ghz Intel i5, 8GB RAM, Java 1.70_17, Akka 2.2.0


SUMMARY

• Combining self-adaptive software systems with principles of MDE to provide systematic and tooled approach for integrating control mechanisms into software applications. !

• A reference implementation and tools facilitating the language use including modeling, code synthesis and verification support.

Thank you

Filip Křikava [email protected]

mailto:[email protected]


CASE STUDIES

HTCondor Client Host

schedd

DAGMan 1

DAGMan 2

DAGMan N

User Interface

Submitworkflows

...

Executes

HTCondor clusterof worker nodes

Users

Spawns

Submit jobs

Case Study 1

Case Study 2


CASE STUDIES

HTCondor Client Host

schedd

DAGMan 1

DAGMan 2

DAGMan N

User Interface

Submitworkflows

...

Executes


Users

Spawns

Submit jobs

Case Study 1

User Interface 1

User Interface 2

User Interface N

Executes


Users

Users

Users

Submit

workflows

Submit jobs

...Central schedd

Case Study 2

ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures

Software

provided effectorpromotion

interconnected

executes htcondor

adaptive software

maintain server

adaptive software

lines levarlogapache2accesslog

output target