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. France
Colorado State University 
Computer Science Department
USA
Université Nice Sophia
Antipolis I3S - CNRS UMR 7271 
France
University Lille 1 / LIFL 
INRIA Lille 
France
Filip Křikava

28.3.2014, SAC’14 - DADS
ACTRESS: Domain-Specific Modeling of Self-Adaptive Software
Architectures
CONTEXT
Jeﬀ 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

28.3.2014, SAC’14 - DADS
Architectures
TOWARDS SELF-ADAPTIVE SOFTWARE SYSTEMS
Monitoring Reconﬁguration
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

28.3.2014, SAC’14 - DADS
Architectures
Engineering of self-adaptive software systems is a challenge
Designing an adaptation
engine
Controller Target System
Transduc
er
+
-
=
mX
i=1
1
d
=
m
d
⇥(N) =
µ =
m
d
µ
d =
m
(N)µ
CHALLENGES

28.3.2014, SAC’14 - DADS
Architectures
Engineering of self-adaptive software systems is a challenge
Designing an adaptation
engine
Transduc
er
+
-
=
mX
i=1
1
d
=
m
d
⇥(N) =
µ =
m
d
µ
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

28.3.2014, SAC’14 - DADS
Architectures
Integrating an adaptation engine
into a target system
Adaptation Engine Target System
Transduc
er
+
-
=
mX
i=1
1
d
=
m
d
⇥(N) =
µ =
m
d
µ
d =
m
(N)µ
API
LOGS
CONFIGURATIONS
COMMANDS
AOP
PROFILER
• Adhoc Implementations
• Extensive handcrafting of non-trivial code
• Cumbersome and error-prone
• Accidental complexities
CHALLENGES

28.3.2014, SAC’14 - DADS
Architectures
Integrating an adaptation engine
into a target system
Adaptation Engine Target System
Transduc
er
+
-
=
mX
i=1
1
d
=
m
d
⇥(N) =
µ =
m
d
µ
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

28.3.2014, SAC’14 - DADS
Architectures
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

28.3.2014, SAC’14 - DADS
Architectures
Decision Making
sensors effectors
Target System
events actions
measures decisions
Transduc
er
+
-
=
mX
i=1
1
d
=
m
d
⇥(N) =
µ =
m
d
µ
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.

28.3.2014, SAC’14 - DADSACTRESS: Domain-Specific Modeling of Self-Adaptive Software
Architectures
FCDL: Feedback Control Definition Language
1

28.3.2014, SAC’14 - DADS
Architectures
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 Reconﬁguration
measures
events
decisions
actions
General Purpose
Language (GPL)Generality
Visibility
Reusability
Distribution
Complex control

28.3.2014, SAC’14 - DADS
Architectures
4. Provide reflection capabilities
5. Embed remoting
Domain-Specific Modeling

28.3.2014, SAC’14 - DADS
Architectures
5. Embed remoting
• Feedback Control Loop
• Sequence of interconnected processes
• Inputs x State -> Output
• Reactive
• Concurrent
• Dynamic
Decision Making
sensors effectorsevents actions
measures decisions

28.3.2014, SAC’14 - DADS
Architectures
5. Embed remoting
• 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

28.3.2014, SAC’14 - DADS
Architectures
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

28.3.2014, SAC’14 - DADS
Architectures
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

28.3.2014, SAC’14 - DADS
Architectures
Idea: service time = fixed overhead + data-size dependent overhead
Abdelzaher et al., 1999, 2002
QoS management control of web servers by content delivery adaptation
Goal: maintain server load around some pre-set value
Prerequisite: preprocessed content (different quality and size)
ILLUSTRATION

28.3.2014, SAC’14 - DADS
Architectures
/1/photo.jpg
/2/photo.jpg
/photo.jpg
full quality
degraded quality
ILLUSTRATION

28.3.2014, SAC’14 - DADS
Architectures
/1/photo.jpg
/2/photo.jpg
/photo.jpg
full quality
degraded quality
normal load
overload
ILLUSTRATION

28.3.2014, SAC’14 - DADS
Architectures
...
serve from
tree #2
serve from
tree #1
Rejection
Level
Minimum Content Full Content
/1/photo.jpg
/2/photo.jpg
/photo.jpg
full quality
degraded quality
normal load
overload
ILLUSTRATION

28.3.2014, SAC’14 - DADS
Architectures
...
serve from
tree #2
serve from
tree #1
Rejection
Level
Minimum Content Full Content
/1/photo.jpg
/2/photo.jpg
/photo.jpg
full quality
degraded quality
normal load
overload
ILLUSTRATION
Distribution Complex control
Generality Visibility Reusability
Using FCDL

28.3.2014, SAC’14 - DADS
Architectures
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)1
2
3

28.3.2014, SAC’14 - DADS
Architectures
ILLUSTRATION
Compute the number of requests (r) and size of responses (w)1
accessLog
: FileTailer
out lines
ﬁle=/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

28.3.2014, SAC’14 - DADS
Architectures
ILLUSTRATION
Generality
Visibility
Reusability
access_log
active processor PeriodTrigger<T> {
pull in port input: T
push out port output: T
!
property initialPeriod = 10.seconds
}
requestCounter
: Accumulator
responseSizeCounter
: Accumulator
scheduler
: PeriodTrigger
loadMonitor
: LoadMonitor
in input
out sum out sum
in requests in size
out utilization
in input
out output
initialPeriod=10s
accessLog
: FileTailer
in lines
out lines
ﬁle=/var/log/apache2/access_log
accessLogParser
: AccessLogParser
Compute the requests rate (R), bandwidth (W) and utilization (U)2

28.3.2014, SAC’14 - DADS
Architectures
ILLUSTRATION
Generality
Visibility
Reusability
content_tree
access_log
utilController
: UtilizationController
requestCounter
: Accumulator
responseSizeCounter
: Accumulator
scheduler
: PeriodTrigger
loadMonitor
: LoadMonitor
in input
out sum out sum
in requests in size
out utilization
in input
out output
in utilization
out contentTree
initialPeriod=10s
adaptor
: ContentAdaptor
in contentTree
accessLog
: FileTailer
in lines
out lines
accessLogParser
: AccessLogParser
k=?
U*=?
Compute severity of adaptation (G)3

28.3.2014, SAC’14 - DADS
Architectures
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
ApacheQOS
utilController
in input
requestCounter
: Accumulator
responseSizeCounter
: Accumulator
scheduler
: PeriodTrigger
loadMonitor
: LoadMonitor
in input
out sum out sum
in requests in size
out utilization
in input
out output
in utilization
out contentTree
system
layer
control
layer
initialPeriod=10s
adaptor
: ContentAdaptor
in contentTree
accessLog
: FileTailer
in lines
out lines
accessLogParser
: AccessLogParser
k=?
U*=?

28.3.2014, SAC’14 - DADS
Architectures
COMPOSITION
Generality
Visibility
Reusability
Hierarchical organization of Adaptive Elements using composites
ApacheQOS utilController
in input
requestCounter
: Accumulator
responseSizeCounter
: Accumulator
scheduler
: PeriodTrigger
loadMonitor
: LoadMonitor
in input
out sum out sum
in requests in size
out utilization
in input
out output
in utilization
out contentTree
out requests
out size
system
layer
control
layer
composite name
initialPeriod=10s
adaptor
: ContentAdaptor
outsize
in contentTree
out size
outrequests
out requests
incontentTree
port promotion
in contentTree
ApacheWebServer
server
: ApacheWebServer
accessLog
: FileTailer
accessLogParser
: AccessLogParser
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
!
}

28.3.2014, SAC’14 - DADS
Architectures
ApacheQOS
control
: QOSControl
in contentTree
apache
: ApacheWebServer
in requests
in size
out requests
out size
out contentTree
control
layer
system
layer
QOSControl
utilController
utilization
: UtilizationMonitor
out contentTree
scheduler
: PeriodTrigger
out utilization
in 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
control
layer
system
layer
QOSControl
utilController
utilization
: UtilizationMonitor
out contentTree
scheduler
: PeriodTrigger
out utilization
in input out output
in utilization
out contentTreein requests in size
in requests in size
COMPOSITION
Generality
Visibility
Reusability

28.3.2014, SAC’14 - DADS
Architectures
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.apache
endpoint=
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
apache: ApacheWebServer
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

28.3.2014, SAC’14 - DADS
Architectures
REFLECTION
Visibility
ApacheQOS
control
layer
sysLoad
: SystemLoad
meta-control
layer
periodController
: PeriodController
out output
in load out period
system
layer
sysLoadTrigger
: PeriodTrigger
in input
out output
in contentTree
apache
: ApacheWebServer
in requests
in size
out requests
out size
out contentTree
QOSControl
scheduler
: PeriodTrigger
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

28.3.2014, SAC’14 - DADS
Architectures
Visibility
Complexcontrol
ApacheQOS
control
layer
sysLoad
: SystemLoad
meta-control
layer
out output
in load out period
system
layer
in contentTree
apache
: ApacheWebServer
in requests
in size
out requests
out size
out contentTree
QOSControl
scheduler
: PeriodTrigger
in input out output
setPeriod
... ...
provided effectorpromotion
control
: QOSControl
periodControl
: AdaptiveMonitoring
REFLECTION - ADAPTIVE MONITORING
Reusability

28.3.2014, SAC’14 - DADS
Architectures
INTERACTION CONTRACTS
in input
: Accumulator
out sum
• Activated on input push request
• Activated on sum pull request

28.3.2014, SAC’14 - DADS
Architectures
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
• ....

28.3.2014, SAC’14 - DADS
Architectures
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")
}

28.3.2014, SAC’14 - DADS
Architectures
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; ; )
}

Architectures
The ACTRESS Modeling Environment
2

28.3.2014, SAC’14 - DADS
Architectures
Modeling
VeriﬁcationCode Generation
Tooling
• Reference implementation of FCDL based on Eclipse Modeling Framework
• Facilitate the use of FCDL
THE ACTRESS MODELING ENVIRONMENT

28.3.2014, SAC’14 - DADS
Architectures
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
utilController
in utilization
out contentTree
k=?
U*=?

28.3.2014, SAC’14 - DADS
Architectures
ACTRESS - CODE GENERATION SUPPORT
accessLogParser accessLog adaptor
apache control
requestCounter
responseSizeCounter
loadMonitor
utilization
scheduler utilController
ApacheQOS
ACTRESS Runtime
actor
actor with
event listener
composite
actor
containment
message
passing
ApacheQOS utilController
in input
requestCounter
: Accumulator
responseSizeCounter
: Accumulator
scheduler
: PeriodTrigger
loadMonitor
: LoadMonitor
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-Text
transformation
ACTRESS
Domain
Framework
FCDL Model
Executable System
• Xbase compiled to Java
• Skeleton implementation

28.3.2014, SAC’14 - DADS
Architectures
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
}
!
// ...
!
}
utilController
in utilization
out contentTree
k=?
U*=?
• Prescriptive
• Restrictive
Visibility

28.3.2014, SAC’14 - DADS
Architectures
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

Architectures
Assessment and Summary
3

28.3.2014, SAC’14 - DADS
Architectures
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
c 0
1
2
1 2
Overall implementation effort
Separation of concerns

28.3.2014, SAC’14 - DADS
Architectures
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

28.3.2014, SAC’14 - DADS
Architectures
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
1
MacBook Pro 2.53 Ghz Intel i5, 8GB RAM, Java 1.70_17, Akka 2.2.0

28.3.2014, SAC’14 - DADS
Architectures
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
filip.krikava@inria.fr

28.3.2014, SAC’14 - DADS
Architectures
CASE STUDIES
HTCondor Client Host
schedd
DAGMan 1
DAGMan 2
DAGMan N
User Interface
Submit
workﬂows
...
Executes
HTCondor cluster
of worker nodes
Users
Spawns
Submitjobs
Case Study 1
Case Study 2

28.3.2014, SAC’14 - DADS
Architectures
CASE STUDIES
HTCondor Client Host
schedd
DAGMan 1
DAGMan 2
DAGMan N
User Interface
Submit
workﬂows
...
Executes
HTCondor cluster
of worker nodes
Users
Spawns
Submitjobs
Case Study 1
User Interface 1
User Interface 2
User Interface N
Executes
HTCondor cluster
of worker nodes
Users
Users
Users
Submit
workﬂows
Submit
jobs
...
Central schedd
Case Study 2

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (13)

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

Semelhante a ACTRESS: Domain-Specific Modeling of Self-Adaptive Software Architectures (20)

Último

Último (20)

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