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 schmidt@dre.vanderbilt.edu Vanderbilt University Nashville, Tennessee Institute for Software Integrated Systems

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

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

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)

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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 http://www.dre.vanderbilt.edu/CoSMIC 19

Questions? 1 - 5 1 - 2 2 1 - 1 1 - 5 1 - 2 2 1 - 1