Model-driven Deployment & Configuration of Component-based Systems

April 22, 2023

Model-driven Deployment & Model-driven Deployment & Configuration of Component-based Configuration of Component-based

SystemsSystems

Krishnakumar Balasubramanian, Boris Kolpackov, Tao Lu, Krishnakumar Balasubramanian, Boris Kolpackov, Tao Lu, Dr. Douglas C. Schmidt, Dr. Aniruddha GokhaleDr. Douglas C. Schmidt, Dr. Aniruddha Gokhale

[email protected]@dre.vanderbilt.eduInstitute for Software Integrated Systems,Institute for Software Integrated Systems,

Vanderbilt UniversityVanderbilt University

Model-driven Deployment & Configuration of Component-based Systems

2Krishnakumar B et al

Overview• Deployment & Configuration of Component-based systems

– Introduction

– Challenges

• Platform-Independent Component Modeling Language (PICML)

• XML Schema Compiler (XSC)

• Deployment And Configuration Engine (DAnCE)



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

Packaging & Deployment

Component Properties

Display

Database

Print

FileComponent Assembly

Database

Display

PrintFile

File Properties

Database Properties



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

Meta-data

Component ComponentMeta-data

Implementation

QoSProperties

Checksum

Version Dependencies

DLL DLL

List of FilesQoS Specs ComponentInterconnections

Assembly

DeploymentApplication

Assembly Assembly

ImplementationDLL DLL

Meta-data

QoSProperties

Checksum


Deployer



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

PIM Data Model Run-time ModelComponent Software

Meta-data to describe component based applications and their requirements

Interfaces to browse, store and retrieve such meta-data

Target Meta-data to describe heterogeneous distributed systems & their capabilities

Interfaces to collect & retrieve such meta-data and commit resources

Execution Meta-data to describe a specific deployment of an application into a distributed system

Prepare environment, Execute on target to Deployment plan, manage lifecycle



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

PlatformIndependentModel (PIM)

Platform Specific Model(PSM) for CCM

PSM forCCM for

IDL

PSM forCCM for

XML

IDL XMLSchema

T1

T2

M1 M2



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

CreatesComponent

ResourceRequirements

Impl Impl Impl

PropertiesDeveloper

Assembler

Creates

Assembler

Component Assembly

ComponentComponent

ComponentComponent

Creates Packager

Component Packages

COMPONENT REPOSITORY

QoS Specs

Configurations

Dependencies

RepositoryAdministrator

Configures

Domain

DomainAdministrator

Specifies

Desktop Printer Laptop computer

Ethernet Bridge

Firewall

Planner

AccessResources

Deployment Plan

Uses

Executor

Deploys



Configuration Challenges• Context

– Configuring & composing component-based applications using XML meta-data

QoSProperties

Checksum




QoSProperties

Checksum



• 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?



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”

Assembly Meta-Model

Component Assembler

Component Development

Component Deployment

AssemblyConstraints

ComponentPackager

Package Meta-Model

Component

ResourceRequirements

Impl Impl Impl

PropertiesComponent Assembly

ComponentComponent

ComponentComponent

PackageConstraints

Component Package

Component Assembly Component Assembly



Example Application: RobotAssembly

Radio

ConveyorPower Switching

Unit

Control Station

Switches

ClockHandler

HumanMachine

Interface*

ManagementWork

Instructions

Disk Storage

StorageDevice

Controller

WatchSetting

Manager*

RobotManager*

PalletConveyorManager

ConveyorDrive System

PalletPresent

Pallet ReleaseSwitch

Off Enable

Fast

Off Enable

Discretes

AssemblyArea

Intrusion

Intrusion Alarm

Robot inWorkArea



RobotAssembly in PICML



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



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

Component Packaging

ApplicationAssemblySystem

Deployment

RunningApplications

Component Packages

(*.cpk)Deployment

Tools

Deployment Plan

Descriptor (.cdp)

Component Domain

Descriptor (.cdd)

AssemblyTools

Component Implementation

Descriptor(*.cid)

PackageConfiguration

Descriptor(.pcd)

Component Interface

Descriptors (.ccd)

Packaging Tools

Component Package

Descriptors (.cpd)

Implementation Artifact

Descriptors (.iad)



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



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)

http://cvs.dre.vanderbilt.edu/

http://cvs.dre.vanderbilt.edu/



Questions?



XML Schema Compiler (XSC)• Context

– Increasing use of XML as a data exchange format

• 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

• Problem– Standard XML parsing API such

as DOM lacks element type information

– Complex implementations to create in-memory representation



Deployment Challenges

• Context– Deploying an application

built using COTS components QoS

PropertiesChecksum




QoSProperties

Checksum



• 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



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

Synergy between CIAO, DAnCE and CoSMIC

CIAO

CoSMICDAnCE



• 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

Node vs. Domain



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



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



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



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

Model-driven Deployment & Configuration of Component-based Systems

Documents

Transcript of Model-driven Deployment & Configuration of Component-based Systems