Evaluating Middleware QoS Configuration Process in DRE Systems

1. Evaluating the Correctness and Effectiveness of a Middleware QoS Configuration Process in DRE Systems Amogh Kavimandan, Anantha Narayanan, Aniruddha Gokhale, Gabor Karsai a.gokhale@vanderbilt.edu www.dre.vanderbilt.edu/~gokhale Presented at ISORC 2008, Orlando, FL May 5-7, 2008 Institute for Software Integrated Systems Dept of EECS, Vanderbilt University Nashville, TN, USA

2. Distributed Real-time and Embedded (DRE) Systems • DRE systems traits: • Composed from diverse, complex sub-systems • Stringent requirements on resources • Multiple, simultaneous QoS requirements at local- (sub-system) and global- (application) level • Heterogeneous platforms • Increasing scale • Trend towards component-based application development • Functionality realized via composition, deployment & configuration of application components on execution platforms 2

3. DRE Systems Software Development Processes DRE systems illustrate the following (non-exhaustive) development stages: Specification – functional description, interface definition, implementation 3

4. DRE Systems Software Development Processes DRE systems illustrate the following (non-exhaustive) development stages: Specification – functional description, interface definition, implementation Composition – functional integration, hierarchical organization & packaging 4

5. DRE Systems Software Development Processes DRE systems illustrate the following (non-exhaustive) development stages: Specification – functional description, interface definition, implementation Composition – functional integration, hierarchical organization & packaging Deployment – computing resource allocation, node placement 5

6. DRE Systems Software Development Processes DRE systems illustrate the following (non-exhaustive) development stages: Specification – functional description, interface definition, implementation Composition – functional integration, hierarchical organization & packaging Deployment – computing resource allocation, node placement Configuration – choosing right set of parameters for hosting infrastructure (e.g., middleware) for actuating application QoS requirements Focus on DRE systems middleware QoS configuration 6

7. Middleware QoS Configuration: Hard Challenges • What vs how - Middleware platforms provide what is required to achieve system QoS not always how it can be achieved • No centralized orchestrator to realize QoS from options providing individual QoS control • Non-trivial to manually perform QoS configuration activity • Choose appropriate configuration mechanisms in an application-specific manner, particularly for large applications • Middleware does not prevent developers from choosing semantically invalid configurations to achieve QoS Lack of effective QoS configuration tools result in QoS policy mis-configurations that are hard to analyze & debug 7

8. Automated Middleware QoS Configuration: Hard Challenges Use DRE system QoS requirements to automated middleware QoS configurations Different DRE systems (e.g., shipboard computing environment, emergency response services) exhibit variability in domain-specific QoS requirements How do we deal with this variability? Must deal with plethora of configuration mechanisms of hosting middleware platforms for muliple m/w platforms How do we bridge the gap between domain-specific requirements and configuration mechanisms? Tool must address the variability and bridge this gap 8

9. QUality of service pICKER (QUICKER): Domain-independent QoS modeling languages – express system QoS in terms of requirements semantics Easier to model, evolve, lesser modeling effort Solution Approach: QUICKER • Shields developers from configuration semantics • Automated translation using model transformation to generate system QoS configurations • Reusable, one-step translation • Encodes best practices in QoS mapping ISORC 2007: General idea of QUICKER RTAS 2008: Model transformation algorithms for CCM/RT 9

10. ISORC 2008: Evaluating QUICKER Is the transformation process correct? We use structural correspondence to prove the transformations correct Are the generated artifacts correct? We use model checking Do the generated configurations deliver the desired QoS? We use empirical validation Focus on the correctness & effectiveness of our QoS configuration process 10

11. Verification framework Specify correctness properties at meta-level Add annotations for each instance (correspondence rules) Use annotations to automatically verify whether the instances satisfy the correctness properties We do not attempt to prove the general correctness of the transformation itself Source Meta Source Model Annotations Correctness Checker Certificate Correctness Specification Model Transformation Target Meta Target Model (1) Verifying the Correctness of QoS Mapping Algorithms 11

12. Input Model crosslink Output Model Correspondence Rules (1) Verifying the Correctness of QoS Mapping Algorithms • Add cross links to identify corresponding elements • Rules specify correspondence conditions for selected types • At the end of the transformation, the instance models are checked if they satisfy all the correspondence conditions 12

13. Component Reference Container End-to-End Priority Propagation Component Home s COMPONENT t e x l F c e EXECUTORS a t a t n c Priority Thread p o e e t C s s c l e t e a Model Pools c n R n a e r f n e r s t e o t n t e p I n n c S E I r e m i v u v n o e o E k Callback C n S s t Interfaces POA COMPONENT SERVER 1 (2) Verifying the Generated QoS Configurations Assembly 1 Assembly n Component Component Reference Reference Container Priority Band Container Component Priority Band Component Home Home s COMPONENT s COMPONENT t t e e x l x l F c F c e e EXECUTORS a t EXECUTORS a a t a t c n t n c p p e o o e t e e s t C s C s l s c e c l a t e t e c e a n n c n a R R n r e a e f r e r f n n e t r e s s t o n e t o t e t n t I e n p n p I n c n E S c I S E e r m I r e i v m u i v v n u v o e n o e o E k Callback o E n k C Callback s S C n t S s t Interfaces Interfaces POA POA ORB Protocol Properties Portable Priorities COMPONENT SERVER 2 COMPONENT SERVER 1 • Dependencies may span beyond “immediate neighbors”, e.g., • application execution path • components belonging to separate assemblies • Empirically validating configuration changes slows down development & QA process considerably • Several iterations before desired QoS is achieved (if at all) 13

14. options of dependent component(s) triggers detection of potential mismatches e.g., dependency between Gizmo invocation priority & Comm lane priority (2) Verifying the Generated QoS Configurations • Leveraging Bogor model checking framework • Dependency structure maintained in Bogor used to track dependencies between QoS options of components, e.g.: • Analysis & Comm are connected • Gizmo & Comm are dependent • Change(s) in QoS Detect mismatch if either values change 14

15. (3) Verifying the Generated QoS Configurations • Representation of middleware QoS options in Bogor model-checker • BIR extensions allow representing domain-level concepts in a system model • QUICKER defines new BIR extensions for QoS options • Allows representing QoS options & domain entities directly in a Bogor input model • e.g., CCM components, Real-time CORBA lanes/bands are first-class Bogor data types • Reduces size of system model by avoiding multiple low-level variables to represent domain concepts & QoS options 15

16. (3) Verifying the Generated QoS Configurations • Representation of properties (that a system should satisfy) in Bogor • BIR primitives define language constructs to access & manipulate domain-level data types, e.g.: • Used to define rules that validate QoS options & check if property is satisfied • Automatic generation of BIR of DRE system from QUICKER-generated output models Model interpreters auto-generate Bogor Input Representation of a system from its model 16

17. QUICKER toolchain provides QoS requirements modeling languages QoS mapping algorithms for mapping requirements to middleware QoS options We discussed verification Concluding Remarks of correctness of QUICKER’s QoS configuration process • Verified the generated QoS configurations through model-checking • Verified the correctness of QoS Mapping Algorithms through structural correspondence • Empirically validated the configurations by applying the QUICKER process to representative DRE system case study • Future work based on capturing variability in requirements & middleware 20 QUICKER can be downloaded from www.dre.vanderbilt.edu/CoSMIC/

18. Questions? 1 - 5 1 0 - 2 0 2 1 - 1 0 0 21

19. BACKUP

20. Overview of QUICKER: Specifying QoS Requirements Challenge 1. QoS requirements specification DRE developers are domain experts who understand domain-level issues, system QoS specification must be expressible at the same level of abstraction 23

21. Overview of QUICKER: Specifying QoS Requirements • Challenge 1. QoS requirements specification • DRE developers are domain experts who understand domain-level issues, system QoS specification must be expressible at the same level of abstraction • Large gap between what is required (by the application) and how it can be achieved (by the middleware platform) • Configurations can not be reused; difficult to scale to large-scale systems 24

22. Overview of QUICKER: Specifying QoS Requirements • Application requirements are expressed as QUICKER QoS policy models • QUICKER captures policies in a platform-independent manner • Specifying QoS is tantamount to answering questions about application; rather than using low-level mechanisms (such as type of publisher proxy collection, event dispatching mechanism etc.) to achieve QoS 25

23. Overview of QUICKER: Specifying QoS Requirements • Application requirements are expressed as QUICKER QoS policy models • QUICKER captures policies in a platform-independent manner • Specifying QoS is tantamount to answering questions about application; rather than using low-level mechanisms (such as type of publisher proxy collection, event dispatching mechanism etc.) to achieve QoS • Representation at multiple levels of granularity • e.g., component- or assembly-level 26

24. Overview of QUICKER: Specifying QoS Requirements • Benefits of QUICKER QoS policy modeling • QoS policy specifications can be containment inherited, reused • QoS policy inherited by all contained objects • More than one connections can share QoS policies • Scalable, flexible QoS policy models 27

25. // Get the correct bands from the < server _ declared _ obj > . policies [ 0 ] = server _ declared _ obj - >_ get _ policy ( RTCORBA :: PRIORITY _ BANDED _ CONNECTION _ POLICY _ TYPE ) ; RTCORBA :: PriorityBandedConnectionPolicy _ var bands _ policy = RTCORBA :: PriorityBandedConnectionPolicy :: _ narrow ( policies [ 0 ]) ; RTCORBA :: PriorityBands _ var bands = bands _ policy - > priority _ bands () ; // Set the proper bands at the object level . Note that a new // object is returned . object = client _ propagated _ obj - >_ set _ policy _ overrides ( policies , CORBA :: SET _ OVERRIDE ) ; Overview of QUICKER: Realizing System QoS iterator: COPY_ON_READ COPY_ON_WRITE DELAYED IMMEDIATE bands: low_prio high_prio fltrgrp: DISJUNCTION CONJUNCTION LOGICAL_AND dispatching: REACTIVE PRIORITY MT scheduling: NULL PRIORITY lanes: static_thrds dyna_thrds TPool: stacksize lane_borrowing request_bufferring • Challenge 2. QoS realization • Very large configuration space providing high degree of flexibility and configurability • Semantic compatibility of QoS configurations enforced via low-level mechanisms – tedious, error-prone • Prune middleware configuration space, instantiate configuration set selected, validate their values 28

26. Overview of QUICKER: Realizing System QoS • Mapping application QoS policies onto configuration options using model transformation developed in GReAT • Semantic translation algorithms specified in terms of input & output languages • e.g., rules that translate multiple application service requests & service level policies to corresponding QoS options • Transformation output as system model – allow for further analysis & translation • Simplifies application development & enhances traceability Level 1 Level 2 Provider Service Request Level 3 Provider Service Levels Multiple Service Requests Service Levels Priority Model Policy Lanes Thread Pool 29

27. Challenge 2 Resolved: Realizing System QoS # of client components and interface operations used to calculate # of threads required • Algorithm shown is RT-CCM QoS mapping that uses • Application structural properties to automatically deduce configurations • Lines 7-16 show thread resource allocation scheme • Line 27 shows client-side QoS configurations • QoS policies specified used for the remaining configurations • Service invocation profile used to assign thread resources • Line 28 resolves priority dependency of connected components 30

28. Overview of QUICKER: Realizing System QoS • Challenge 3. QoS options dependency resolution of application sub-systems • Configurations of connected components may exhibit dependency relationship • e.g., server-side priority model and client-side priority bands must match • Manually tracking dependencies between components is hard 31