1. Model-driven Deployment & Configuration of Component-based Systems
Krishnakumar Balasubramanian, Boris Kolpackov, Tao Lu, Dr. Douglas C. Schmidt, Dr. Aniruddha Gokhale
Institute For Software Integrated Systems,
Vanderbilt University
February 18, 2019

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

3. Overview of CORBA 2.x Standard
CORBA 2.x is distributed object computing (DOC) middleware that shields applications from heterogeneous platform dependencies
e.g., languages, operating systems, networking protocols, hardware
CORBA 2.x simplifies development of distributed applications by automating/encapsulating
Object location
Connection & memory mgmt.
Parameter (de)marshaling
Event & request demultiplexing
Error handling & fault tolerance
Object/server activation
Concurrency
Security
CORBA defines interfaces & policies, not implementations

4. Limitations of CORBA 2.x Specification
Requirements of non-trivial DOC applications:
Collaboration of multiple objects & services
Deployment on diverse platforms
Limitations – Lack of standards for
Server configuration
Object/service configuration
Application configuration
Object/service deployment
Consequence: tight couplings at various layers
Brittle, non-scalable implementation
Hard to adapt & maintain
Increased time-to-market
Boiler Plate X
Boiler Plate Y
Server
Obj Impl
Obj Impl
Obj Impl
Config C
Config B
Config A
Server
Obj Impl
Obj Impl
COS
Svc
ORB/POA
ORB/POA
CORBA BUS
Client
Server
Obj Impl
Obj Impl
COS
Svc
invoke
Lack of server configuration standards  Boiler plate code (with slight differences) for ORB and POA initialization and resource management
Lack of object/service configuration standards  application specific code entangled thru out
Lack of application configuration  intertwined spaghetti code throughout application
Lack of object/service deployment  Hard to refactor application topology, manual/non-standard deployment mechanisms
ORB/POA

5. Solution: Component Middleware
Component middleware capabilities:
Creates a standard “virtual boundary” around application component implementations that interact only via well-defined interfaces
Define standard container mechanisms needed to execute components in generic component servers
Specify the infrastructure needed to configure & deploy components throughout a distributed system

6. Birdseye View of Component Middleware
Components encapsulate application “business” logic
Components interact via ports
Provided interfaces, e.g.,facets
Required connection points, e.g., receptacles
Event sinks & sources
Attributes
Containers provide execution environment for components with common operating requirements
Components/containers can also
Communicate via a middleware bus and
Reuse common middleware services …
Container …
Middleware Bus
Container …
Security
Replication
Notification
Persistence
Scheduling
A/V Streaming
Load Balancing

7. CORBA 2.x Application Development Lifecycle
Specification of IDL interfaces of objects

8. CORBA 2.x Application Development Lifecycle
Implement servants & write all the code required to bootstrap & run the server
CORBA 2.x supports programming by development (engineering) rather than programming by assembly (manufacturing)

9. CCM Application Development Lifecycle
Specification of supported interfaces of components

10. CCM Application Development Lifecycle
Specification of provided & required interfaces of components

11. CCM Application Development Lifecycle
Implementation of component executors, plus association of components with component executors & their homes

12. CCM Application Development Lifecycle
Grouping of component implementation artifacts & meta-data descriptors into component packages

13. CCM Application Development Lifecycle
Specification of component inter-connections & composition of component assembly packages

14. CCM Application Development Lifecycle
Deploy components onto target nodes according to the deployment plan

15. Motivation for Deployment & Configuration
Packaging & Deployment
Component Properties
Display
Database
Print
File
Component
Assembly
File Properties
Database Properties
Goals
Ease component reuse
Build complex applications by assembling existing components
Deploy component-based application into heterogeneous domain
Separation of concerns
Component development
Application assembly
Application deployment
Application configuration
Server configuration

16. 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

17. 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

18. 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

19. 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

20. Configuration Challenges
Context
Configuring 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?

21. 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”

22. 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*
Control Station
Robot in
Work
Area
Storage
Device
Controller
Disk Storage
Clock
Handler

23. RobotAssembly in PICML

24. 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 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)
Grouping of all of the above

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

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

27. 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

28. 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

29. 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
CoSMIC
DAnCE

30. 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

31. 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

32. 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

33. 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

34. 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

35. Concluding Remarks Model-driven Deployment & Configuration PICML
Models component-based systems
Improves design-time validation of systems
Generates component meta-data
XSC
Relieves XML parsing related activities from programmers
DAnCE
Deploys component-based systems in a standardized fashion
Tools Availability
(DAnCE, XSC)
(CoSMIC)