Title: QUICKER: A Model-driven QoS Mapping Tool for QoS-enabled Component Middleware
1QUICKER A Model-driven QoS Mapping Tool for
QoS-enabled Component Middleware
Amogh Kavimandan, Krishnakumar Balasubramanian,
Nishanth Shankaran, Aniruddha Gokhale, Douglas
C. Schmidt schmidt_at_dre.vanderbilt.edu
2Background
- COTS middleware technologies
- Raise the level of abstraction
- Support a number of Quality of Service (QoS)
configuration knobs
- Flexibility in configuration complicates DRE
system development - System QoS now depends on how middleware is
configured - Achieving desired QoS increasingly becoming
configuration problem than design problem
Lack of effective QoS configuration tools result
in QoS policy mis-configurarions that are hard to
analyze debug
3Motivating Application
- NASAs Magnetospheric MultiScale (MMS) space
mission - Consists of four identically instrumented
spacecraft, ground control system - Collect mission data
- Send it to ground control at appropriate time
instances - MMS mission QoS requirements span across two
dimensions - Multiple modes of operation
- Varying importance of data collection activity of
satellite sensors - Need to translate QoS requirements into QoS
options as well as resolve QoS dependencies
4Challenge 1 Translating policies to
configuration options
Prioritized service invocations (QoS Policy)
needs to be mapped to Banded Connection (QoS
configuration)
- Large gap between application QoS policies
middleware QoS configuration options - Necessary to realize the desired QoS policies
- Not a straightforward mapping
- Requires understanding of middleware
configuration space - e.g., multiple levels of QoS requires configuring
appropriate number of thread pools, threadpool
lanes (server) and banded connections(client)
5Challenge 2 Choosing appropriate values for QoS
options
- Individually configuring components is tedious
error-prone - e.g., 140 QoS options for MMS mission
- Choosing valid values for configuration options
inherently doesnt scale well as size of
application increases
6Challenge 3 Validating QoS options
- Each QoS option value chosen has to be validated
- Every system reconfiguration (design time) should
be validated - e.g., reconfiguration of bands of Analysis should
be validated such that the modified value
corresponds to (some) lane priority of Comm
component
6
7Challenge 4 Resolving QoS options
dependencies(2/2)
ThreadPool priorities of Comm should match
priority bands defined at Gizmo
- Manually tracking dependencies difficult or in
some cases infeasible - Dependent components may belong to more than one
assembly - Dependency may span beyond immediate neighbors
- e.g., dependency between Gizmo and Comm
components - Empirically validating a change in configuration
slows down design process considerably - Several iterations before desired QoS is achieved
(if at all)
7
8Solution Approach Model-Driven QoS Mapping
- QUality of service pICKER (QUICKER)
- Allows modeling of application QoS policies
- Provides automatic mapping of QoS policies to
configuration options - Allows validating the generated QoS options
- Automated QoS mapping and validation process
can be used iteratively in the design process
9Enabling Technologies
- Enhanced Platform Independent Component Modeling
Language (PICML), a DSML for modeling CCM
applications - QoS Mapping using Graph Rewriting and
Transformation (GReAT) model transformation tool - Customized Bogor model-checker to define new
types and primitives to validate QoS options
- Uses model interpreters to automate generation of
system specification in Bogor
9
10QUICKER concepts Transformation of QoS
policies(1/2)
- Representation of application QoS policies
- Platform-independent semantics closely follow
application QoS requirements - Representation of policies at component- or
assembly-level - Representation of QoS options
- Component QoS Modeling Language (CQML) captures
CCM-specific QoS configuration options
RequirementProxy can be per component or assembly
instance
11QUICKER concepts Transformations of QoS
policies(2/2)
- Translation of policies into QoS options
- Semantic translation rules specified in terms of
input (PICML) and output (CQML) type graph - QUICKER Transformation engine performs mapping of
QoS policies (in PICML) to QoS configuration
options (in CQML)
11
12QUICKER concepts Validation of QoS options(1/2)
- Representation of middleware QoS options in Bogor
- Bogor extensions allow representing domain-level
concepts of system model - QUICKER defines new Bogor extension for QoS
options - Uses Bogor Input Representation (BIR) at a higher
level of abstraction - e.g., Component, lane, band etc. data types
defined in QoS extensions - Reduces size of the system model by avoiding
(redundant) auxiliary variables in specification
13QUICKER concepts Validation of QoS options(2/2)
- Representation of properties (that a system
should satisfy) in Bogor - BIR primitives define language constructs to
access manipulate domain-level data types - Used to define rules that validate options and
check if property is satisfied - Used to construct dependency structure of
components which is needed for validation of
connected components - Automatic generation of BIR specification from
CQML models
Rule determines if ThreadPool priorities at Comm
match with priority bands at Analysis
13
14Resolving Challenge 1 Translating policies to
options (1/2)
- Expressing QoS policies
- Allow modeling application-level QoS policies at
high-level of abstraction - e.g., Multiple service levels support for Comm
component, service execution at varying priority
for Analysis component - Reduces modeling effort ( 25 QoS policy elements
for MMS mission)
15Resolving Challenge 1 Translating policies to
options (2/2)
- Mapping policies to options
- Model transformations automate the tedious
error-prone translatation process - Reduced development time
- Transformations generate QoS configuration
options as CQML models - Allow further analysis/transformation by other
tools - Traceability in development process
15
16Resolving Challenges 2 3 Ensuring validity of
QoS options
- Model interpreter used to generate BIR
specification from CQML models - BIR primitives used to check whether a given set
of QoS options satisfies a system property - e.g., fixed priority service execution, a
property of Comm component - Supports iterative validation of QoS options
during QoS configuration process
17Resolving Challenge 4 Resolving QoS options
dependencies
- Use dependency structure to track dependencies
between QoS options of connected (e.g., Comm and
Analysis) or dependent (e.g., Comm and Gizmo)
Detect mismatch if either values change
- Change(s) in
- QoS options of
- dependent component(s) causes detection of
potential mismatches - e.g, dependency between gizmo invocation priority
and Comm lane priority values - Dependencies resolved at design time
18Related Work
- Functional Specification Analysis Tools
- Hatcliff, J. et. al. (2003). Cadena
- QoS Adaptation Modeling Tools
- Ye, J. et. al. (2004). DQME
- Zinky, J., (1997). QuO
- QoS Specification Tools
- Ritter, T. et. al. (2003). CCM QoS MetaModel
- Ahluwalia, J. et. al. (2005). Model-based
Run-time - Monitoring
- Frolund, S. et. al. (1998). QML
- Schedulability Analysis Tools
- Madl, G. et. al. (2004). Automatic
Component-based system verification - Kodase, S. et. al. (2003). AIRES
18
19Concluding Remarks
- QUICKER
- Model-Driven Engineering (MDE)-based approach
- Maps application-level QoS policies to
middleware-specific QoS configuration options - Model transformations automatically generate QoS
options - Model-checking extensions ensure validity of QoS
options at component- and application-level
Available as Open-Source tools http//www.dre.vand
erbilt.edu/CoSMIC
19
20Questions?
1
-
5
1
0
-
2
0
2
1
-
1
0
0
1
-
5
1
0
-
2
0
2
1
-
1
0
0