1. 11/14/2018
QUICKER: A Model-driven QoS Mapping Tool for QoS-enabled Component Middleware
Amogh Kavimandan, Krishnakumar Balasubramanian, Nishanth Shankaran,
Aniruddha Gokhale, Douglas C. Schmidt
Vanderbilt University Nashville, Tennessee
Institute for Software Integrated Systems

2. Background COTS middleware technologies Raise the level of abstraction
11/14/2018
Background
COTS middleware technologies
Raise the level of abstraction
Support a number of Quality of Service (QoS) configuration knobs
Container
COMPONENT
EXECUTORS
Component
Home
POA
Callback
Interfaces I n t e r a l f c s E v S i k F R p o u
Reference C m x
COMPONENT SERVER 1
COMPONENT SERVER 2
ORB
End-to-End Priority
Propagation
Thread
Pools
Portable Priorities
Protocol Properties
Priority Band
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

3. Motivating Application
11/14/2018
Motivating Application
NASA’s 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

4. Challenge 1: Translating policies to configuration options
11/14/2018
Challenge 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)

5. Challenge 2: Choosing appropriate values for QoS options
11/14/2018
Challenge 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 doesn’t scale well as size of application increases

6. Challenge 3: Validating QoS options
11/14/2018
Challenge 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

7. Challenge 4: Resolving QoS options dependencies(2/2)
11/14/2018
Challenge 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

8. Solution Approach: Model-Driven QoS Mapping
11/14/2018
Solution 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

9. Enabling Technologies
11/14/2018
Enabling 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

10. QUICKER concepts: Transformation of QoS policies(1/2)
11/14/2018
QUICKER 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

11. QUICKER concepts: Transformations of QoS policies(2/2)
11/14/2018
QUICKER 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

12. QUICKER concepts: Validation of QoS options(1/2)
11/14/2018
QUICKER 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

13. QUICKER concepts: Validation of QoS options(2/2)
11/14/2018
QUICKER 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

14. Resolving Challenge 1 : Translating policies to options (1/2)
11/14/2018
Resolving 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)

15. Resolving Challenge 1 : Translating policies to options (2/2)
11/14/2018
Resolving 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

16. Resolving Challenges 2 & 3 : Ensuring validity of QoS options
11/14/2018
Resolving 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

17. Resolving Challenge 4: Resolving QoS options dependencies
11/14/2018
Resolving 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

18. Related Work Functional Specification & Analysis Tools
11/14/2018
Related 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
Cadena provides a framework for lightweight dependency analysis of behavior of components. Cadena also supports an integrated modelchecking infrastructure dedicated to checking global system properties using event-based inter-component communication. The difference between Cadena and QUICKER is that Cadena applies model-checking to verify functional behavior of components, whereas QUICKER applies model-checking to verify QoS configuration options of component middleware.
The Distributed QoS modeling environment (DQME) is a DSML that enables the design of QoS adaptive applications in combination
with using QoS provisioning frameworks, such as QuO. DQME uses a hierarchical representation for modeling QoS adaptation
strategies and supports design of controllers based on state machines. DQME focuses on a high-level design of QoS adaptation strategies, whereas QUICKER’s emphasis is more fine-grained and focuses on the runtime configuration options of the underlying middleware.
Ritter et.al. describes CCM extensions for generic QoS support and discusse a QoS metamodel that supports domain-specific multi-category QoS
contracts.
Ahluwalia focuses on capturing QoS properties in terms of interaction patterns amongst system components that are involved in executing a particular service and supporting run-time monitoring of QoS properties by distributing them over components (which can be monitored) to realize that service.
In contrast to these two works, QUICKER focuses on automating the error-prone activity of mapping platform-independent QoS policies to middleware-specific QoS configuration options.
Work by Madl et. al. maps application models captured in the Embedded Systems Modeling Language (ESML) to UPPAAL timed automata using graph transformation to verify properties like schedulability of a set of real-time tasks. AIRES is a model-driven analysis tool that evaluates whether certain timing, memory, power, and cost constraints of realtime and embedded applications are satisfied.
QUICKER is complementary to these efforts since it emphasizes mechanisms to translate design-intent into actual configuration options of underlying middleware and verify that both the transformation and subsequent modifications to the configuration options remain semantically valid. 18

19. Available as Open-Source tools http://www.dre.vanderbilt.edu/CoSMIC
11/14/2018
Concluding 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 19

20. Questions? 1 - 5 1 - 2 2 1 - 1 1 - 5 1 - 2 2 1 - 1