Model-driven%20Deployment%20

1
Model-driven Deployment Configuration of
Component-based Systems

• Krishnakumar Balasubramanian, Boris Kolpackov,
  Tao Lu, Dr. Douglas C. Schmidt, Dr. Aniruddha
  Gokhale
• kitty_at_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
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

PIM Data Model Run-time Model
Component 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
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
Discretes
Intrusion Alarm
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
lt!-Component Implementation Descriptor(.cid)
associates components with impl. artifacts--gt
ltDeploymentComponentImplementationDescriptiongt  
ltUUIDgtFB9D7161-1765-4784-BC1D-EA9EAAB3ED2Alt/UUIDgt
  ltimplements href"RobotManager.ccd" /gt
ltmonolithicImplgt ltprimaryArtifactgt  
ltnamegtRobotManager_execlt/namegt  
ltreferencedArtifact href"RobotManager_exec.iad"
/gt   lt/primaryArtifactgt ltprimaryArtifactgt
  ltnamegtRobotManager_stublt/namegt  
ltreferencedArtifact href"RobotManager_stub.iad"
/gt   lt/primaryArtifactgt ltprimaryArtifactgt
  ltnamegtRobotManager_svntlt/namegt  
ltreferencedArtifact href"RobotManager_svnt.iad
/gt   lt/primaryArtifactgt   lt/monolithicImplgt lt/Dep
loymentComponentImplementationDescriptiongt
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
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