CaDAnCE: A Criticality-aware Deployment And Configuration Engine

1. Institute for Software Integrated Systems Vanderbilt University Nashville, Tennessee CaDAnCE: A Criticality-aware Deployment And Configuration Engine Gan Deng, Douglas Schmidt & Aniruddha Gokhale www.dre.vanderbilt.edu Presented at ISORC 2008 Orlando, FL, USA, May 5-7, 2008

2. New Demands on Open Distributed Real-time & Embedded (DRE) Systems … … … … Container Container Middleware Bus Replication Security Persistence Transaction Open Distributed real-time & embedded (DRE) systems • Network-centric & larger-scale “systems of systems” • Dynamic context • Stringent simultaneous QoS demands • e.g., scalability, dependability, throughput

3. NASA MMS Mission System Case Study C Three Operational String Example B A • Operational String A A mission-critical task that collects important field data when a satellite moves to particular locations • High criticality • Operational String B Domain-centric data analysis based on predefined analysis models • Medium criticality • Operational String C  Collect auxiliary field data occasionally, such as Sun zenith, satellite view zenith (only when requested by B) • Low criticality

4. Operational String Deployment: OMG D&C Facet Facet Event Sink Event Sink App App App App startLaunch startLaunch install spawn spawn startLaunch • Operational string deployment via Synchronous Method Invocation (SMI) • ExecutionManager (EM) iteratively makes synchronous invocation on each NodeManager (NM) to install components • Each NM propagates component port references back to the EM • DAM dispatches component port object references to NMs for connection establishment, i.e., fulfill dependency requirement between components

5. Challenge 1: Avoid Deployment Order Inversion • Context • A deployment order is the order in which operational strings are deployed, which is determined by the dependencies between operational strings • Problem • Deployment order inversion happens when a higher criticality operational string has a dependency to a lower criticality operational string • A deployment order inversion can propagate across multiple operational strings due to such dependencies

6. Challenge 2: Preserve Predictability of Other Operational Strings • Context • The dynamic nature of open DRE systems requires on-demand deployment of a number of operational strings in one request • Each operational strings has certain utility value to the entire DRE system • Problem • While the D&C framework improves the predictability of high-criticality operational strings by minimizing their D&C latencies, it should also preserve the D&C predictability of other operational strings

7. Our Solution  The CaDAnCE Approach Develop an D&C framework called Criticality-Aware Deployment And Configuration Engine (CaDAnCE) Based on our prior work on DAnCE Step 1  Convert a set of operational strings (based on XML-based deployment descriptors) into a set of directed graphs Step 2  Recompose the graphs based on operational strings criticalities & their dependency relationships by promoting components from one to another Step 3  Convert recomposed graphs back into a new set of in-memory operational strings Benefit: Minimize D&C latency of mission-critical operational strings

8. Overview of the Recomposition Algorithm in CaDAnCE • Sort & iterate through all the operational strings, from the highest criticality to the lowest • Process all the external dependencies of each operational string sequentially • For each operational string, identify the components causing deployment order inversion by tracing criticality-inverted dependency trace • Remove all external dependencies causing deployment order inversion by promoting components from lower criticality ones to higher criticality ones Component Promoting Component Promoting Removing all criticality-inverted dependencies avoids deployment order inversion

9. Predictability  Parallel Deployment via AMI/AMH startLaunch App App App App startLaunch install install spawn spawn startLaunch ? • Asynchronous deployment & serializability • Apply Asynchronous Method Invocation (AMI) to take advantage of parallel processing among many nodes • AMI, however, does not provide a mechanism to coordinate different nodes, which is required by D&C for connection establishment • To ensure serializability of D&C process, we combine AMI with Asynchronous Method Handling (AMH)

10. Empirical Evaluation of CaDAnCE – HW/SW Testbed • Run experiments on a prototype implementation of NASA MMS Mission System • 15 components in a sample operational strings • Experimented with up to 64 operational strings & 960 components in total • Experiments performed in the ISIS Lab • Dual 2.8 GHz Xeon CPUs, 1GB of ram, 40GB HDD, & gigabit ethernet cards • Real-time Fedora Core 4 Linux kernel version 2.6.20-rt8-UNI • Used up to 6 nodes

11. Effects on Operational String Recomposition Low Medium High • Hypothesis • CaDAnCE should not change the functional correctness while producing correct dependencies between operational strings • Experimental design • The experiments consist of 3 operational strings with criticality level of high, medium, and low, respectively • Before the experiment, 2 arbitrary criticality-inverted external dependencies are populated • Measure the total # of components & # of dependencies (both internal & external) of each operational string before & after applying the CaDAnCE algorithm

12. Results & Analysis for the Experiment • CaDAnCE reduced the D&C latency of high criticality operational strings significantly (Both w/ AMI/AMH & w/o AMI/AMH) • Without AMI/AMH, the total end-to-end latency of all operational strings increased due to component distribution effect • With AMI/AMH, the total end-to-end latency of all operational strings is almost the same as without CaDAnCE Without AMI/AMH With AMI/AMH CaDAnCE minimizes D&C latency of mission-critical operational strings

13. D&C Latency vs. Criticality • Hypothesis • CaDAnCE can avoid deployment order inversion when higher criticality operational strings have dependencies on lower criticality operational strings • Experimental design • Two experiments with different operational string configurations • The first experiment has 3 operational strings with low operational string growth effect • Each string has 15 components evenly distributed across 5 nodes • The second experiment has 2 strings with high operational string growth effect (worst case scenario) • Same configuration as above High Growth Effect Low Growth Effect

14. Results & Analysis for the Second Experiment • The latency of deploying the high criticality operational string is nearly the same as deploying it without applying the CaDAnCE algorithm • However, the D&C latency of low criticality operational string increases & becomes the same as that of high criticality string • Due to the operational string merge effect • In worse case scenario, CaDAnCE performs the same as baseline, i.e., without using CaDAnCE CaDAnCE preserves predictability of lower criticality strings in case of merge

15. Concluding Remarks • Component middleware has already received widespread acceptance in enterprise business domains • e.g.,J2EE, Web Services • Developers of DRE systems have encountered limitations with the available component middleware platforms • This research applies methodologies & techniques to improve both the human productivity & computing performance of D&C of component-based DRE systems • Our techniques are most relevant with below two component models: • OMG CORBA Component Model • OSOA Service Component Architecture (SCA) Open-source software can be downloaded from www.dre.vanderbilt.edu/CIAO & www.dre.vanderbilt.edu/CoSMIC

16. Thank You