Model-driven Deployment & Configuration of Component-based Systems

1. Model-driven Deployment & Configuration of Component-based Systems Krishnakumar Balasubramanian, Boris Kolpackov, Tao Lu, Dr. Douglas C. Schmidt, Dr. Aniruddha Gokhale kitty@dre.vanderbilt.edu Institute for Software Integrated Systems, Vanderbilt University

2. Overview • Deployment & Configuration of Component-based systems • Introduction • Challenges • Platform-Independent Component Modeling Language (PICML) • XML Schema Compiler (XSC) • Deployment And Configuration Engine (DAnCE)

3. Display Database Properties File Properties File Print Database Display File Print Database Packaging & Deployment Component Assembly Component Properties Motivation for Deployment & Configuration • Goals • Ease component reuse • Build complex applications by assembling existing components • Standardize deployment of applications into heterogeneous domains • Separation of concerns • Component development • Application assembly • Application deployment • Application configuration • Middleware configuration

4. OMG Deployment & Configuration Spec • Specification defines deployment of component-based applications • Intended to replace Packaging & Deployment chapter of CCM specification • Meta-information is captured using XML descriptors • Platform Independent Model (PIM) • Defined in two dimensions • Data models vs. management (run-time) models • Component software vs. target vs. execution

5. Platform-independent Model (PIM) Dimensions • Modeling view-points • Conceptual, logical, & physical view-point • Platform-independent model • Conceptual & logical viewpoint of deployment & configuration • Defined in two-dimensions

6. PIM Mapping to CCM • Physical viewpoint • Mapping from PIM to platform specific model (PSM) for CCM • Set of transformations • T1  PIM to PSM for CCM • T2  PSM to • PSM for IDL • PSM for XML • Set of mapping rules • M1  PSM to IDL • M2  PSM to XML schema

7. Deployment & Configuration Activities • Descriptors are passive entities • Manipulated by Actors • Different Stages • Development • Developer • Assembler • Packager • Target • Domain Administrator • Deployment • Repository Administrator • Planner • Executor • Actors are abstract

8. Configuration Challenges • Context • Configuring & composing component-based applications using XML meta-data • Problem • Meta-data split across multiple XML descriptors • Complex inter-dependencies between descriptors • XML is error-prone to read/write manually • No guarantees about semantic validity (only syntactic validation possible) • If meta-data is wrong, what about the application?

9. Platform-Independent Component Modeling Language • Solution • PlCML • Developed in Generic Modeling Environment (GME) • Core of Component Synthesis using Model-Integrated Computing (CoSMIC) toolchain • Capture elements & dependencies visually • Define “static semantics” using Object Constraint Language (OCL) • Define “dynamic semantics” via model interpreters • Also used for generating domain specific meta-data • “Correct-by-construction”

10. Example Application: RobotAssembly Conveyor Power Switching Unit Conveyor Drive System Management Work Instructions Radio Intrusion Alarm Discretes Pallet Present Switches Pallet Release Switch Human Machine Interface* Watch Setting Manager* Pallet Conveyor Manager Off Enable Off Enable Fast Assembly Area Intrusion Robot Manager* Robot in Work Area Control Station Storage Device Controller Disk Storage Clock Handler

11. RobotAssembly in PICML

12. Types Of Meta-data generated by PICML(1/2) • Component Interface Descriptor (.ccd) • Describes the interface, ports, properties of a single component • Implementation Artifact Descriptor (.iad) • Describes the implementation artifacts (e.g., DLLs, OS, etc.) of a single component • Component Package Descriptor (.cpd) • Describes multiple alternative implementations of a single component • Package Configuration Descriptor (.pcd) • Describes a specific configuration of a component package • Component Implementation Descriptor (.cid) • Describes a specific implementation of a component interface • Contains component inter-connection information • Component Deployment Plan (.cdp) • Plan which guides the actual deployment • Component Domain Descriptor (.cdd) • Describes the target domain of deployment • Component Packages (.cpk) • Aggregation of all of the above

13. Types Of Meta-data generated by PICML(2/2)

14. Example output for RobotAssembly <!–-Component Implementation Descriptor(.cid) associates components with impl. artifacts--><Deployment:ComponentImplementationDescription> <UUID>FB9D7161-1765-4784-BC1D-EA9EAAB3ED2A</UUID> <implementshref="RobotManager.ccd" /> <monolithicImpl> <primaryArtifact> <name>RobotManager_exec</name> <referencedArtifacthref="RobotManager_exec.iad" /> </primaryArtifact> <primaryArtifact> <name>RobotManager_stub</name> <referencedArtifacthref="RobotManager_stub.iad" /> </primaryArtifact> <primaryArtifact> <name>RobotManager_svnt</name> <referencedArtifacthref="RobotManager_svnt.iad“ /> </primaryArtifact> </monolithicImpl> </Deployment:ComponentImplementationDescription>

15. Concluding Remarks • PICML • Models component-based systems • Improves design-time validation of systems • Generates component meta-data • Future work • Scalability issues • Traditional system analysis • Complete system generation aka “Middleware Compiler” • Generated optimized systems aka “Optimizing Middleware Compiler” • Available as open-source • http://cvs.dre.vanderbilt.edu (CoSMIC)

16. Questions?

17. XML Schema Compiler (XSC) • Context • Increasing use of XML as a data exchange format • Problem • Standard XML parsing API such as DOM lacks element type information • Complex implementations to create in-memory representation • Solution • XML Schema Compiler (XSC) • Static typing using a set of mapping rules • Generates C++ (Native/CORBA) from XML schema • Generates parser for creating in-memory representation of XML files • Customizable code generation using traversal mechanism

18. Deployment Challenges • Context • Deploying an application built using COTS components • Problem • Complex applications • Large no. of components • Micro-management of components • Difficulty in reasoning complete end-to-end behaviour • Manual deployment inherently error-prone • Ad hoc scripts no better

19. Synergy between CIAO, DAnCE and CoSMIC Deployment And Configuration Engine (DAnCE) • Solution • Deployment & Configuration Engine (DAnCE) • First-cut implementation of deployment infrastructure • Partial implementation of the following interfaces: • RepositoryManager • NodeManager • NodeApplicationManager • DomainApplicationManager • NodeApplication • ExecutionManager • Processes XML meta-data generated by PICML CIAO CoSMIC DAnCE

20. Node vs. Domain • Domain* provides functionality at the domain level • Node* provides similar functionality but are restricted to a Node • ApplicationManager • Deals with application launch and tear-down • Application • Deals with creation, control of component homes & components

21. Planning • Component Packages are installed into the Component Repository • RepositoryManager parses XML meta-data into in-memory representation • Executor creates global deployment plan and passes it along to DomainApplicationManager • DomainApplicationManager splits it into multiple local plans • Contacts NodeManager to create appropriate NodeApplicationManagers

22. Initiating Application Launch • Executor initiates launching of the application • DomainApplicationManager creates a DomainApplication object • Furthers application launch by contacting individual NodeApplicationManagers • NodeApplicationManagers create appropriate number of NodeApplications

23. Completing Application Launch • Executor notifies DomainApplication of completion of application launch • DomainApplication initiates NodeApplications to complete application launch • Connections between components are done at this stage • At the end of this stage, Components are ready to handle calls from clients

24. Application Teardown • Executor initiates tear-down by first terminating the running applications • DomainApplicationManager ensures tear down of NodeApplications • It then tears down all the managers