A Platform-Independent Component Modeling Language for DRE Systems

1
A Platform-Independent Component Modeling
Language for DRE Systems

• Krishnakumar Balasubramanian, Jaiganesh
  Balasubramanian,
• Jeff Parsons, Aniruddha Gokhale, Douglas C.
  Schmidt
• kitty_at_dre.vanderbilt.edu
• Department of EECS,
• Vanderbilt University

2
Motivating Application

• Emergency Response System
• Monitor terrain
• Unmanned Aerial Vehicles (UAVs)
• Capture images
• Send images to control center
• Key QoS parameters
• Image Tx Latency
• Network Bandwidth
• Multiple mission modes
• Image processing
• Multiple Simultaneous QoS requirements

3
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
• Component-Integrated ACE ORB (CIAO)
• Our CCM implementation based on The ACE ORB (TAO)
• http//www.dre.vanderbilt.edu/CIAO

4
UAV System Components

• System Resource Manager
• Global QoS manager
• Control Center Display
• User interaction
• Policy specification
• Image Stream(s)
• Sender/Receiver
• Tx/Rx images
• Local Resource Manager
• Local QoS manager
• Qoskets
• QoS enforcer
• QoS predictors
• QoS helpers
• Built using Component-Integrated ACE ORB (CIAO)
• dist-systems.bbn.com/papers

5
CCM Deployment Configuration Process
6
Building UAV system using CCM

• Identify components define interfaces
• Define Component IDL
• Define component interactions
• Define connections between components using XML
• Compose application
• Define instantiations of components
• Generate metadata
• Deploy the application onto its run-time platform
• Define a mapping between components nodes
• Refine the application to incorporate changes

7
Component-based UAV system Challenges (1/5)

• Accidental complexities in interface definition
• Differences between CORBA 2.x and CORBA 3.x (CCM)
• New keywords in the language
• Subtle differences in syntax and semantics of
  equivalent elements
• CORBA 2.x interfaces
• CORBA 3.x components

// CORBA 3.x component ImageProvider
component ImageViewer component LRM
ImageProvider, ImageViewer // Operations
on LRM
// CORBA 2.x interface ImageProvider
interface ImageViewer interface LRM
ImageProvider, ImageViewer // Operations
on LRM
8
Component-based UAV system Challenges (2/5)

• Defining consistent component interactions
• Textual IDL definition
• Edit-Compile-Fix Cycle
• No inter-connections
• No whole system view

component MultiReceiver ImageProcessingQosket
consumes ResourceAllocationEvt resourceEvt
consumes PolicyChangeEvt policyEevt

• component SystemResourceManager
• attribute double available_cpu
• attribute double available_bw
• attribute double needed_cpu
• attribute double needed_bw
• attribute UAV_List uavs_from_lrm
• uses multiple LRMInterface my_lrms
• provides SRMInterface srm_interface
• publishes ResourceAllocationEvt resourceEvt
  publishes PolicyChangeEvt policy_evt

9
Component-based UAV system Challenges (3/5)

• Associating components with targets
• Map software artifacts to physical system
• Match component requirements with target
  capabilities
• Performed in an ad-hoc fashion
• By different people
• At different periods in time

10
Component-based UAV system Challenges (4/5)
ltassemblyImplgt ltinstance xmiid"ScaleQosket"gt
ltnamegtScaleQosketlt/namegt ltpackage
href"ScaleQosket.cpd"/gt lt/instancegt ltinstance
xmiid"LocalResourceManagerComponent"gt
ltnamegtLocalResourceManagerComponentlt/namegt
ltpackage href"LocalResourceManagerComponent.cpd"/
gt lt/instancegt ... ltconnectiongt
ltnamegtincoming_image_outgoing_image_Evtlt/namegt
ltinternalEndpointgt ltportNamegtoutgoing_im
age_Evtlt/portNamegt ltinstance
xmiidref"LocalReceiver"/gt
lt/internalEndpointgt ltinternalEndpointgt
ltportNamegtincoming_image_Evtlt/portNamegt
ltinstance xmiidref"MultiReceiver"/gt
lt/internalEndpointgt lt/connectiongt lt/assemblyImpl
gt

• Generating valid deployment descriptors
• XML is non-intuitive
• Error-prone to write manually
• No way to propagate changes automatically
• Redundant effort
• Cascading effect

11
Component-based UAV system Challenges (5/5)

• Automating propagation of changes
• Typical in DRE systems evolution
• Currently changes propagated in an ad-hoc fashion
  
• Redundant effort
• Cascading effect
• Change to a single UAV stream
• Needs to get propagated to all instances of the
  stream
• 1 stream per UAV
• n streams in total (ngt50)
• Difficult to estimate effect of changes

12
Model-Driven Development (MDD)-based Solution

• Platform-Independent Component Modeling Language
• Developed using 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
  
• Generates domain specific meta-data

Goal Correct-by-construction
13
Challenge 1 Resolved Constraints for IDL

• Visual component interface definition
• Import/Export IDL
• Define IDL rules as OCL constraints
• Example
• An abstract Event can have no concrete parent a
  concrete Event can have at most one.

let concrete_parents self.parts
("Inherits")-gt select (x gmeModel
x.oclAsType (Event).abstract false) in if
(self.abstract true) then
concrete_parents-gtsize 0 else
concrete_parents-gtsize lt 2 endif
14
Challenge 2 Resolved Visual composition

• Semantically compatible component interaction
  definition
• Enforce static constraints using OCL
• Enforce dynamic constraints via a model
  interpreter

15
Challenge 3 Resolved Deployment Planning

• Target domain definition
• Describe domain resources
• Describe inter-connections
• Mapping components
• Components ? Nodes
• Requirements ? Capabilities
• Optimize communication path
• Exploit locality ? Collocate

16
Challenge 4 Resolved Generate metadata

• Define model interpreters
• Generate descriptors using interpreters
• Ensures validity
• Syntactic
• Semantic
• Relieve DRE developers from learning yet another
  technology
• Save time

17
Challenge 5 Resolved Hierarchical Composition

• 4 streams x 11 components per stream x 3
  connections per component
• Too much to comprehend at once n streams (n gt
  100) gt ???
• Model single stream
• Reuse stream multiple times
• Increased comprehension
• Automate propagation of changes

18
Related Work

• CADENA
• Integrated Environment to apply static analysis
  using model-checking
• VEST
• DSML developed in GME
• Pre-defined component Libraries
• Aspect checks
• Prescriptive aspect library
• ESML
• DSML developed in GME
• Targets PRiSM (Boeings Bold-stroke component
  model)
• Ptolemy II
• Modeling, simulation, and design of concurrent
  systems
• Allows defining systems based on Models of
  Computation

cadena.projects.cis.ksu.edu
www.cs.virginia.edu/stankovic/vest.html
www.isis.vanderbilt.edu/projects/mobies
ptolemy.eecs.berkeley.edu
19
Concluding Remarks

• PICML
• DSML based approach
• Support for component-based development
• Design-time
• Specify component functionality
• Component interactions
• Assembly Packaging of components
• Deployment-time
• Specification of target environment
• Automatic Deployment plan generation
• Available as open-source
• CoSMIC
• www.dre.vanderbilt.edu/ cosmic
• CVS Repository
• cvs.dre.vanderbilt.edu

20
Questions?
21
Deployment Configuration

• OMG Specification
• Defines deployment of component-based
  applications
• Meta-information is captured using XML
  descriptors
• Defines a Platform Independent Model (PIM) in two
  dimensions
• Data vs. management (run-time)
• Software vs. target vs. execution
• Different Stages
• Development
• Developer
• Assembler
• Packager
• Target
• Domain Administrator
• Deployment
• Repository Administrator
• Planner
• Executor

22
Example Meta-data generated by PICML

• 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

ltDeploymentComponentImplementationDescriptiongt  
ltUUIDgtFB9D7161-1765-4784-BC1D-EA9EAAB3ED2Alt/UUIDgt
  ltimplements hrefSender.ccd" /gt
ltmonolithicImplgt ltprimaryArtifactgt  
ltnamegtSender_execlt/namegt   ltreferencedArtifact
hrefSender_exec.iad" /gt   lt/primaryArtifactgt
ltprimaryArtifactgt   ltnamegtSender_stublt/namegt
  ltreferencedArtifact hrefSender_stub.iad"
/gt   lt/primaryArtifactgt ltprimaryArtifactgt
  ltnamegtSender_svntlt/namegt  
ltreferencedArtifact hrefSender_svnt.iad /gt  
lt/primaryArtifactgt   lt/monolithicImplgt lt/Deploymen
tComponentImplementationDescriptiongt
23
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

24
Model-Driven Development (MDD)

• Models as basic artifact in all stages of system
  development
• Definition of Domain-Specific modeling languages
  (DSMLs)
• Concrete Syntax, Abstract Syntax, Semantic
  Domain, Syntactic Mapping, Semantic Mapping
• Meta-models, models, model-transformations, code
  generators

25
Generic Modeling Environment (GME)

• Tool Developer (Metamodeler)
• GME used to develop a domain-specific graphical
  modeling environment
• Define syntax, static semantics, visualization
  of the environment
• Semantics implemented via interpreters

• Application Developer (Modeler)
• Uses a specific modeling environment (created by
  metamodeler w/GME) to build applications
• The interpreter produces something useful from
  the models
• e.g., code, simulations, configurations

http//www.isis.vanderbilt.edu/Projects/gme/defaul
t.htm
26
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
27
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

28
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
29
(No Transcript)