model-driven engineering of component systems vanderbilt university nashville, tennessee institute...

Model-Driven Engineering of Component Systems

Vanderbilt University Nashville, Tennessee

Institute for Software Integrated Systems

Proposal Defense, March 3rd, 2006

Krishnakumar [email protected]

www.dre.vanderbilt.edu/~kitty

2

Presentation Road Map

• Motivation• Technology Context• Overview of Research Challenges• Research Area 1: Composition of Component

Systems• Research Area 2: Expression of Design Intent• Research Area 3: Application-Specific

Optimizations• Summary of Research Contributions• Concluding Remarks

3

Where We Started: Object-Oriented Programming

• Object-oriented (OO) programming simplified software development through higher level abstractions & patterns, e.g.,

Well-written OO programs exhibit recurring structures that promote abstraction, flexibility, modularity, & elegance

• Decoupling interfaces & implementations

• Associating related data & operations

operation1()operation2()operation3()operationn()

data

class X

4

Distributed Object Computing (DOC) Middleware

• Applies the Broker pattern to abstract away lower-level OS & protocol-specific details for network programming

• Creates distributed systems that are easier to model & build using OO techniques

• Result: robust distributed systems built with distributed object computing (DOC) middleware

• e.g., CORBA, Java RMI, etc.

1 1Proxy

service

Service

service

AbstractService

service

Client

We now have more robust software & more powerful distributed systems

operation()Object :

Interface X: Client

Middleware

5

Traditional DOC Middleware Limitations• Unable to provide multiple, alternate

views per client

Component

Client C

Client A

6


views per client

• Unable to navigate between interfaces in a standardized fashion

Component

Client C

Client A

7


views per client


• Extensibility restricted to language (Java, C++) and/or platform (CORBA) C++ Component

Java Component C++ Component C# Component

8

Traditional DOC Middleware Limitations• Unable to provide multiple,

alternate views per client


• Extensibility restricted to language (Java, C++) and/or platform (COM, CCM)

• Specification & enforcement of policy

• Done via low-level mechanisms, i.e., by writing code

// Get the correct bands from the <server_declared_obj>. policies[0] = server_declared_obj->_get_policy (RTCORBA::PRIORITY_BANDED_CONNECTION_POLICY_TYPE); RTCORBA::PriorityBandedConnectionPolicy_var

bands_policy = RTCORBA::PriorityBandedConnectionPolicy ::_narrow (policies[0]); RTCORBA::PriorityBands_var bands = bands_policy->priority_bands ();

// Set the proper bands at the object level. Note that a new // object is returned. object = client_propagated_obj->_set_policy_overrides(policies,

CORBA::SET_OVERRIDE);

9


views per client


• Extensibility restricted to language (Java, C++) and/or platform (COM, CCM)

• Specification & enforcement of policy

• Done via low-level mechanisms, i.e., by writing code

• Accidental complexities

• Middleware configuration is complex, tedious & error-prone

• Ad hoc deployment mechanisms

• Tedious, error-prone

• Not reusable

Significant challenges for system developers!

QoSProperties

Checksum

Version Dependencies

List of FilesQoS Specs ComponentInterconnections

ImplementationDLL DLL

QoSProperties

Checksum

Version Dependencies

ImplementationDLL DLL

10





11

Component Middleware

• Components encapsulate “business” logic

• Components interact via ports• Provided interfaces• Required interfaces• Event sinks & sources• Attributes

• Allow navigation between ports• Containers provide execution

environment for components• Components/containers can also

• Communicate via a middleware bus & reuse common middleware services

SecurityReplication NotificationPersistence

SchedulingA/V Streaming Load Balancing

Middleware Bus

…

Container

… …

…

Container

Components allow reasoning about systems at higher level of abstraction

e.g., CORBA Component Model (CCM), Microsoft .NET Web Services, Enterprise Java Beans (EJB)

12

Interface Design

Component Design

Component Implementation

Component Packaging

ApplicationAssembly

SystemDeployment

Interface IDL Definitions

Stubs&

Skeletons

Object Implementations

RunningApplications

Component IDL

Definitions

IDL Compiler

CIDL Compiler

Component CIDL

Definitions

Servants,Executors,Contexts

Language Tools

Component DLLs

Component & Home Properties

Component Interface

Descriptors (.ccd)

Packaging Tools



Descriptors (.cid)

DeploymentTools

Implementation Artifact

Descriptors (.iad)

Deployment Plan

Descriptor (.cdp)

AssemblyTools


Descriptor(*.cid)

Component Package

Descriptors (.cpd)

MonolithicComponentDescription

Component Package

Descriptors (.cpd)

Component Assembly

Descriptors

realizes

realizes

uses

DeploymentPlanning

DeploymentPlanning

Tools

ComponentDomain

Descriptor(.cdd)


realizes

Component System Development Lifecycle

Specification of supported interfaces

13

Interface Design

Component Design


Component Packaging

ApplicationAssembly

SystemDeployment


Stubs&

Skeletons


RunningApplications

Component IDL

Definitions

IDL Compiler

CIDL Compiler

Component CIDL

Definitions


Language Tools

Component DLLs


Component Interface

Descriptors (.ccd)

Packaging Tools



Descriptors (.cid)

DeploymentTools


Descriptors (.iad)

Deployment Plan

Descriptor (.cdp)

AssemblyTools


Descriptor(*.cid)

Component Package

Descriptors (.cpd)


Component Package

Descriptors (.cpd)

Component Assembly

Descriptors

realizes

realizes

uses

DeploymentPlanning

DeploymentPlanning

Tools

ComponentDomain

Descriptor(.cdd)


realizes


Specification of component types, e.g.,

provided & required interfaces

14

Interface Design

Component Design


Component Packaging

ApplicationAssembly

SystemDeployment


Stubs&

Skeletons


RunningApplications

Component IDL

Definitions

IDL Compiler

CIDL Compiler

Component CIDL

Definitions


Language Tools

Component DLLs


Component Interface

Descriptors (.ccd)

Packaging Tools



Descriptors (.cid)

DeploymentTools


Descriptors (.iad)

Deployment Plan

Descriptor (.cdp)

AssemblyTools


Descriptor(*.cid)

Component Package

Descriptors (.cpd)


Component Package

Descriptors (.cpd)

Component Assembly

Descriptors

realizes

realizes

uses

DeploymentPlanning

DeploymentPlanning

Tools

ComponentDomain

Descriptor(.cdd)


realizes



15

Interface Design

Component Design


Component Packaging

ApplicationAssembly

SystemDeployment


Stubs&

Skeletons


RunningApplications

Component IDL

Definitions

IDL Compiler

CIDL Compiler

Component CIDL

Definitions


Language Tools

Component DLLs


Component Interface

Descriptors (.ccd)

Packaging Tools



Descriptors (.cid)

DeploymentTools


Descriptors (.iad)

Deployment Plan

Descriptor (.cdp)

AssemblyTools


Descriptor(*.cid)

Component Package

Descriptors (.cpd)


Component Package

Descriptors (.cpd)

Component Assembly

Descriptors

realizes

realizes

uses

DeploymentPlanning

DeploymentPlanning

Tools

ComponentDomain

Descriptor(.cdd)


realizes


Grouping of component implementation artifacts

& metadata into component packages

16

Interface Design

Component Design


Component Packaging

ApplicationAssembly

SystemDeployment


Stubs&

Skeletons


RunningApplications

Component IDL

Definitions

IDL Compiler

CIDL Compiler

Component CIDL

Definitions


Language Tools

Component DLLs


Component Interface

Descriptors (.ccd)

Packaging Tools



Descriptors (.cid)

DeploymentTools


Descriptors (.iad)

Deployment Plan

Descriptor (.cdp)

AssemblyTools


Descriptor(*.cid)

Component Package

Descriptors (.cpd)


Component Package

Descriptors (.cpd)

Component Assembly

Descriptors

realizes

realizes

uses

DeploymentPlanning

DeploymentPlanning

Tools

ComponentDomain

Descriptor(.cdd)


realizes


Specification of component interconnections &

composition of component assembly packages

17

Interface Design

Component Design


Component Packaging

ApplicationAssembly

SystemDeployment


Stubs&

Skeletons


RunningApplications

Component IDL

Definitions

IDL Compiler

CIDL Compiler

Component CIDL

Definitions


Language Tools

Component DLLs


Component Interface

Descriptors (.ccd)

Packaging Tools



Descriptors (.cid)

DeploymentTools


Descriptors (.iad)

Deployment Plan

Descriptor (.cdp)

AssemblyTools


Descriptor(*.cid)

Component Package

Descriptors (.cpd)


Component Package

Descriptors (.cpd)

Component Assembly

Descriptors

realizes

realizes

uses

DeploymentPlanning

DeploymentPlanning

Tools

ComponentDomain

Descriptor(.cdd)


realizes


Specification of deployment target domain & configuration

of component assembly

18

Interface Design

Component Design


Component Packaging

ApplicationAssembly

SystemDeployment


Stubs&

Skeletons


RunningApplications

Component IDL

Definitions

IDL Compiler

CIDL Compiler

Component CIDL

Definitions


Language Tools

Component DLLs


Component Interface

Descriptors (.ccd)

Packaging Tools



Descriptors (.cid)

DeploymentTools


Descriptors (.iad)

Deployment Plan

Descriptor (.cdp)

AssemblyTools


Descriptor(*.cid)

Component Package

Descriptors (.cpd)


Component Package

Descriptors (.cpd)

Component Assembly

Descriptors

realizes

realizes

uses

DeploymentPlanning

DeploymentPlanning

Tools

ComponentDomain

Descriptor(.cdd)


realizes


Deploy component assembly packages onto target nodes

according to a deployment plan

19





20

Component System Development Challenges• Lack of system composition tools

Component

ResourceRequirements

Impl Impl Impl

Properties

Component Assembly

ComponentComponent

ComponentComponent

21


• Complexity of declarative platform API & notations

<assemblyImpl>

<instance xmi:id="ScaleQosket">

<name>ScaleQosket</name>

<package href="ScaleQosket.cpd"/>

</instance>

<instance xmi:id="LocalResourceManagerComponent">

<name>LocalResourceManagerComponent</name>

<package href="LocalResourceManagerComponent.cpd"/>

</instance>...<connection>

<name>incoming_image_outgoing_image_Evt</name>

<internalEndpoint>

<portName>outgoing_image_Evt</portName>

<instance xmi:idref="LocalReceiver"/>

</internalEndpoint>

<internalEndpoint>

<portName>incoming_image_Evt</portName>

<instance xmi:idref="MultiReceiver"/>

</internalEndpoint>

</connection>

</assemblyImpl>

OS KERNEL

OS I/O Subsystem

Network Interfaces

OS KERNEL

OS I/O Subsystem

Network Interfaces

MIDDLEWARE

ComponentComponent

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

XML

XMLXML

XML

22



• Composition overhead in large-scale systems

Node Application

Container

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CH

Receptacle

Facet

Event Sink

Event SourceComponent Home

Component Assembly

Component Remote Invocation

Collocated Invocation

Creates

23

Component System Development Challenges

My research provides tools to design & optimize “systems-in-the-large”

• Lack of system composition tools


• Composition overhead in large-scale systems

• Emphasis still on programming-in-the-small

• Whack-a-mole approach to system development

• Violation of Don’t Repeat Yourself (DRY) principle

• Need abstractions for expressing system level design intent

24

Component Assembler

Component Assembly

Component Component

Component Component

Component Package

Component Assembly

Component Component

Component Component

Component Assembly

Component Component

Component Component

(1)

Inte

rfac

e D

efin

ition

(2) Interaction Definition

(3) Hierarchical Composition

(5) Metadata Generation

(4) Assembly Optimization

Component Developer

Component Packager

ComponentDeployer

PICMLco

mposition

asse

mbl

y

optimization

gene

ratio

n

specification

Assembly

Deployment

Assembly

Assembly

DAnCE Framework

Component


Implementation

Properties

ImplementationImplementation

Solution Approach: PICML

• System Composition Technologies - A Domain-Specific Modeling Language (DSML) to allow component specification & composition

• System Optimization Technologies – System optimization infrastructure• Generative Technologies – Metadata generation infrastructure

Generative Technologies

System Composition Technologies System

Optimization Technologies

25

Control Center SystemResource

Manager

ScaleQosket

CropQosket

Compress Qosket

LocalResourceManager

Cropping QoSPredictorScaling QoS

Predictor

Compression QoSPredictor

Image Feeds (.NET Web

Service)

• System Resource Manager

• Global QoS manager• Control Center

• User interaction• .NET Web Services

• Image Stream(s)• Local Resource

Manager• Local QoS

manager• Qoskets

• QoS enforcer• QoS predictors

• QoS estimators• Built using the

Component-Integrated ACE ORB (CIAO)

Example Scenario: Emergency Response System

Developed for DARPA PCES program (dist-systems.bbn.com/papers/)

26





27

• Component middleware allows composition across multiple dimensions

• Temporal – Static vs. dynamic

Research Area 1: Composition of Component Systems

Static Dynamic

Time

Hierarchical

Flat

Str

uct

ura

lComponent Assembly

Component Component

Component ComponentComponent Component

Component Component

Deployment Time

Build Time

Component Assembly

28

• Component middleware allows composition across multiple dimensions

• Temporal – Static vs. dynamic• Structural – Flat vs. hierarchical

• Systems are no longer built from scratch

• Composed from COTS components & frameworks using design patterns

Research Area 1: Composition of Component Systems

Static Dynamic

Time

Hierarchical

Flat

Str

uct

ura

lComponent Assembly

Component Component

Component ComponentComponent Component

Component Component

Deployment Time

Build Time

Component Assembly

29

Related ResearchCategory Related Research

Component Environments

G. Karsai et al, A Modeling Language & Its Supporting Tools for Avionics Systems, In Proceedings of 21st Digital Avionics Systems Conf., Aug. 2002.

Lüer, C. & Rosenblum, D. S. 2001, WREN---an environment for component-based development, SIGSOFT Soft. Eng. Notes 26, 5 (Sep. 2001), 207-217.

Jack Greenfield et al, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, Wiley, 2004

Programming Models

G. T. Heineman & W. T. Councill, editors, Component-Based Software Engineering: Putting the Pieces Together, Addison-Wesley, 2001.

Czarnecki, K. & Eisenecker, U. W. Generative Programming: Methods, Tools, & Applications, ACM Press/Addison-Wesley Publishing Co., 2000

Batory, D. et al, Scaling step-wise refinement, in Proceedings of the 25th International Conference on Software Engineering (Portland, Oregon, May 03 - 10, 2003).

Functional Verification

J. Hatcliff et. al., Cadena: An Integrated Development, Analysis, & Verification Environment for Component-based Systems, in Proceedings of the 25th International Conference on Software Engineering, (Portland, OR), May 2003.

J. A. Stankovic et al, VEST: An Aspect-based Composition Tool for Real-time Systems, in Proceedings of the IEEE Real-time Applications Symposium, (Washington,DC), IEEE, May 2003.

30

Related Research: What’s Missing?• Tool-specific component

technologies• As opposed to component-

technology agnostic tools!• Emphasis on component

programming models /languages• How to write better

components?• Lack of deployment-time tool

support• No support for deployment

artifacts!• Lack of tool support for system

level development

It’s not just the functionality, it’s the packaging!

Component


Impl Impl Impl

Properties

Component Assembly

ComponentComponent

ComponentComponent

31

1.Lack of tool support for defining consistent component interactions• Primitive interface definition

tools: EditCompileRun Fix cycle

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; };

Control Center Display

SystemResourceManager


Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket

Compression QoS Predictor

Scaling QoS Predictor

Cropping QoS Predictor

Stream 4

Stream 3

Stream 2

Stream 1

System Composition: Unresolved Challenges

32




Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket




Stream 4

Stream 3

Stream 2

Stream 1

1.Lack of tool support for defining consistent component interactions• Primitive interface definition

tools: EditCompileRun Fix cycle

• No inter-connection information

2.Lack of integrated system view• Design view, e.g., UML models• Development view, e.g., Visual

Studio

component MultiReceiver

: ImageProcessingQosket

{

consumes ResourceAllocationEvt

resourceEvt;

consumes PolicyChangeEvt

policyEevt;

};

Integrated view of the system is essential!

System Composition: Unresolved Challenges

33




Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket




Stream 4

Stream 3

Stream 2

Stream 1

3.Lack of tool support for multi-level composition

• Change propagation done in an ad-hoc fashion

• Redundant & error-prone

• Violates “Don’t Repeat Yourself” (DRY) principle

• Need support for different composition granularities

4.Lack of context-aware policy specification mechanisms

• No one size fits all!

5.Lack of scalable techniques for composition

• Manual techniques don’t scale well

Lack of tool support negates benefits of components!

System Composition: Unresolved ChallengesPolicy A

Policy A’

34

Solution Approach: DSML Infrastructure• Platform-Independent

Component Modeling Language (PICML)• Developed using GME• Core of Component

Synthesis using Model-Integrated Computing (CoSMIC) toolchain

• Capture elements & dependencies visually

35





• Define “static semantics” using Object Constraint Language (OCL)

36





• Define “static semantics” using Object Constraint Language (OCL)

• Define “dynamic semantics” via model interpreters

• Employ generative technologies

Component Developer

IDL Files

Domain Expert

Define domain elemets

Import/Export IDL

Define interfaces

Associate components with domain elements

PICML

Model Application

Application Model

Application Developer

Refine application during life-time

Target Domain Model

Model interfaces

Deployment Descriptors

37

Solution Approach: System Composition Tools• Disallow inconsistent

component interactions

• Provide integrated view of system

• Support system composition across multiple levels

• Support context-dependent policy specifications

• Support scalable composition techniques

• Support integration with component build tools & component repositories

Pol

ResIma

Stream1

Pol

ResIma

Stream2

Pol

ResIma

Stream3

Pol

ResIma

Stream4

pol

res

inc

out

MultiReceiver[ MultiReceiver ]

blupol

res

SystemResourceManager[ SystemResourceManager ]

c3

c1

c2

c4

c5

c6

publish

deliverTo

deliverTo

deliverTo

deliverTo

publish

deliverTo

deliverTo

deliverTo

deliverTo

publish

deliverTodeliverTo

deliverTo

publish

deliverTo

deliverTo

deliverTo

publish

publish

qos

ScaleQosPredictor[ ScaleQosPredictor ]

imainccur

out

CompressQosket[ CompressQosket ]

imainccur

out

DiffServQosket[ Dif fServQosket ]

cpu

CPUBrokerComponent[ CPUBrokerComponent ]

imainccur

out

ScaleQosket[ ScaleQosket ]

qos

CroppingQosPredictor[ CroppingQosPredictor ]

inc out

LocalReceiver[ LocalReceiver ]

PolicyChangeEvt

ResourceAllocationEvt

ImageGenerationEvt

qos

CompressionQosPredictor[ CompressionQosPredictor ]

imasen

out

Sender[ Sender ]

polresinccomscacrodifcpu

imaoutcrosca

com

LocalResourceManagerComponent[ LocalResourceManagerComponent ]

imainccur

out

CropQosket[ CropQosket ]

invoke

emit

emit

delegatesTo

delegatesTo

emit

delegatesTo

invoke

invoke

invoke

invoke

emit

invoke

emit

invokeinvoke

Policy A

Policy A’

38

Challenges 1 & 2 Resolved: Visual Interaction Definition

ima

inc

cur

out


qos


pol

res

inc

com

sca

cro

ima

out

cro

sca

com

dif

cpu


ima

inc

cur

out


ima

senout

Sender[ Sender ]

qos


qos


ima

inc

cur

out


cpu


inc out


PolicyChangeEvt


ImageGenerationEvt

ima

inc

cur

out


delegatesTo

delegatesTo

emit

invoke

invoke

invokeinvoke

invoke

emit emit emit

invoke

invokeinvoke

emit

delegatesTo

1.Syntactically compatible component interaction definition• Enforce platform semantics using OCL

constraints

Disallow inconsistent component interactions

39

Challenges 1 & 2 Resolved: Visual Interaction Definition

ima

inc

cur

out


qos


pol

res

inc

com

sca

cro

ima

out

cro

sca

com

dif

cpu


ima

inc

cur

out


ima

senout

Sender[ Sender ]

qos


qos


ima

inc

cur

out


cpu


inc out


PolicyChangeEvt


ImageGenerationEvt

ima

inc

cur

out


delegatesTo

delegatesTo

emit

invoke

invoke

invokeinvoke

invoke

emit emit emit

invoke

invokeinvoke

emit

delegatesTo

1.Syntactically compatible component interaction definition• Enforce platform semantics using OCL

constraints2.High-level integrated view of system

• In addition to multiple task-specific views of the same system

K Balasubramanian et al, “Applying Model-Driven Development to Distributed Real-time & Embedded Avionics Systems,” the International Journal of Embedded Systems,

special issue on Design & Verification of Real-Time Embedded Software, April 2005

Provide integrated view of system

40

Challenges 3 & 4 Resolved: Hierarchical Composition3.Allow composition across multiple levels

• Components, assemblies of components & assemblies of assemblies

• Propagate changes automatically• Define assemblies as types• Instantiate multiple times

Support system composition across multiple levels

41

Challenges 3 & 4 Resolved: Hierarchical Composition3.Allow composition across multiple levels

• Components, assemblies of components & assemblies of assemblies

• Propagate changes automatically• Define assemblies as types• Instantiate multiple times

4.Policy/Configuration can be specified

• At component level• Overridden at assembly

level(s)

K Balasubramanian et al, “A Platform-Independent Component Modeling Language for Dist-ributed Real-time & Embedded Systems,” Journal of Computer & System Sciences, 2006

Support context-dependent policy specifications

42

Challenge 5 Resolved: Scalable System Composition 5.Integrate support for scalable

composition techniques

• Aspect-Oriented Modeling

• Addresses scalability of modeling effort

• C-SAW tool

• Developed by SOFTCOM (UAB)

• C-SAW with PICML

• Provides template configurations (using ECL) that are weaved into a model

• User can customize the templates depending on application requirements

K. Balasubramanian et al, “Weaving Deployment Aspects into Domain-Specific Models,” the International Journal on Software Engineering & Knowledge Engineering, 2006 (Accepted)

Support scalable composition techniques

43

Research Contributions

Category Benefits Publications

System Composition Technologies

• Support static composition of systems by ensuring that the components get built correctly

• Support dynamic composition of systems by ensuring that the connections between components are correct

• Provide integrated view of system

• Address composition scalability concerns by employing model-weaving technologies

1. IEEE Workshop on Object-oriented Real-time Dependable Systems (WORDS), 2003.

2. International Journal of Embedded Systems, Special issue on Design & Verification of Real-Time Embedded Software, 2005.

3. Elsevier Journal of Computer & System Sciences, 2006.

4. International Journal on Software Engineering & Knowledge Engineering, 2006. (Accepted)

44

System Composition: Proposed Enhancements• Integrate with portable infrastructure

build tools like MakeProjectCreator• Exploit application context

information to take advantage of native platform build tool capabilities, e.g.:• Alter the visibility of symbols

• Elevate implementation artifact abstraction• Allows managing components in

terms of packages• Push metadata into Repository

Manager to allow execution of meta-queries, e.g.:• “Do you have a sensor with

latency specification < 6 µs?”• “Give me a database capable of

handling 2,000 transactions/sec”

Component


Impl Impl Impl

Properties

Component Assembly

ComponentComponent

ComponentComponent

45

Proposed Enhancements: Evaluation Criteria• Baseline for comparison

• Deployment of a system with existing tools (vanilla CIAO & DAnCE)

• Eliminate the need to manually write build scripts

• Reduce static footprint per component type by 20%

• Simple changes already yield 10%

• Total savings accrue based on number of unique types per assembly

• Automate the creation of component packages

• Ability to automatically deploy a package into the Repository Manager

PICML

COMPONENT REPOSITORY

QoS Specs

Configurations

Dependencies

46





47

Research Area 2: Expression of Design Intent• Traditional middleware had a

significant gap between design intent & its expression using 3rd generation languages

• Component middleware helps bridge this gap by replacing imperative techniques with declarative techniques

• Examples:

• Describing connection between components

• Describing constituents of component packages

• Configuration of components

• Configuration of middleware infrastructure

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

OS KERNEL

OS I/O Subsystem

Network Interfaces

OS KERNEL

OS I/O Subsystem

Network Interfaces

MIDDLEWARE

ComponentComponent

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

XML

XMLXML

XML

48


Operating System

John DeTreville, Making System Configuration More Declarative, Proceedings of the 10th Work. on Hot Topics in Operating Systems, June 2005, USENIX.

Bryan Cantrill et al, Dynamic Instrumentation of Production Systems, USENIX Annual Technical Conference, 2004

Lionel Cons & Piotr Poznanski, Pan: A High-Level Configuration Language, LISA, Proceedings of the 16th Conference on Systems Administration (LISA 2002), 2002, pp.83-98

Software Description

R. Chinnici et al, Web Services Description Language (WSDL) 2.0 part 1: Core language, August 2004, http://www.w3.org/TR/2004/WD-wsdl20-20040803.

Dashofy, E. M. et al, An infrastructure for the rapid development of XML-based architecture description languages, Proceedings of the 24th international Conference on Software Engineering (Orlando, Florida, May 19 - 25, 2002)

Middleware Packaging

Richter, J., Applied Microsoft .NET Framework Programming, Microsoft Press, 2002.

Sun Microsystems, Enterprise Java Beans Specification, Version 2.1, 2002

Middleware Communication

M Rose, The Blocks Extensible Exchange Protocol Core (BEEP), RFC 3080, March 2001

Don Box et al, Simple Object Access Protocol (SOAP) 1.1, http://www.w3.org/TR/2000/NOTE-SOAP-20000508

49

<assemblyImpl>




</instance>






<internalEndpoint>



</internalEndpoint>

<internalEndpoint>



</internalEndpoint>

</connection>

</assemblyImpl>

Related Research: What’s Missing?• Declarative techniques use

tool-friendly technologies to express design intent

• Example: XML

• XML is non-intuitive

• Error-prone to write manually

• Changes to system require changes to generated XML

• Redundant effort

• Problems with imperative techniques not solved

• Declarative techniques shifted the problem into a different space

• “Whack-a-mole” approach

Support for declarative notations of component middleware is critical!

Is id unique?

Does portName refer to a valid port?

Is idref a valid reference?

50

Expression of Design Intent: Unresolved Challenges

1.Complexity of Declarative Notations

• Example 1: CORBA Interface Definition Language (IDL)

• Differences between CORBA 2.x & CORBA 3.x (CCM)

• New keywords in the language

• Subtle differences in syntax & semantics of similar elements

–CORBA 2.x interfaces

–CORBA 3.x components

// CORBA 3.xcomponent ImageProvider {};component ImageViewer {};component LRM : ImageProvider, ImageViewer

{ // Operations on LRM

};

// CORBA 2.xinterface ImageProvider {};interface ImageViewer {};interface LRM : ImageProvider,

ImageViewer{ // Operations on LRM

};

Accidental complexities are present in every technology!

51

Expression of Design Intent: Unresolved Challenges• Example 2: .NET manifests

• Each assembly in .NET can be associated with manifests

• Policy specifications for assembly, user, domain

• Configuration of assembly• Manifest names are closely

associated with assembly names• Foo.dll Foo.dll.manifest• Foo.dll Foo.dll.config

• OS loader ignores configurations in files with other names

2.Lack of support for system evolution• Interfaces & metadata of

individual components needs to evolve with the system

Need flexible abstractions to express design intent!

Policy

`

Group

Application Assembly Manifest

User

Component


Implementation

Properties


Component Assembly Configuration

Component Assembly Manifest

Application Assembly Configuration

52

PICML (CCM)

PICML (.NET)

CCM Models

.NET Web Service Models

PICML (CCM+.NET)

GME Composition

CCM Deployment descriptors

.NET Deployment descriptors



CCM+.NET Web Service

Models

Solution Approach: Model-Driven Generation• Provide high-level

abstractions for specification of design intent

• Automate generation of platform-specific metadata from these abstractions

• Provide support for system interface & metadata evolution

• Provide support for developing heterogeneous systems

53

Challenge 1 Resolved: Automate Generation of Metadata

1.High-level, user-friendly visual abstractions for declarative notations

• Define a type system that captures the platform semantics

• e.g., CCM, .NET

ModelInterpreters

Application Model

<connection> <name>compressionQosPredictor_qosLevels</name> <internalEndpoint> <portName>qosLevels</portName> <instance xmi:idref="CompressionQosPredictor"/> </internalEndpoint> <internalEndpoint> <portName>compressionQosPredictor</portName> <instance xmi:idref="LocalResourceManagerComponent"/> </internalEndpoint></connection>

Generated Descriptors

N N N N

N

N

N

N

NN

Application Model Abstract Syntax Tree

Provide high-level abstractions for specification of design intent

54

Challenge 1 Resolved: Automate Generation of Metadata

1.High-level, user-friendly visual abstractions for declarative notations

• Define a type system that captures the platform semantics

• e.g., CCM, .NET

ModelInterpreters

Application Model

<connection> <name>compressionQosPredictor_qosLevels</name> <internalEndpoint> <portName>qosLevels</portName> <instance xmi:idref="CompressionQosPredictor"/> </internalEndpoint> <internalEndpoint> <portName>compressionQosPredictor</portName> <instance xmi:idref="LocalResourceManagerComponent"/> </internalEndpoint></connection>

Generated Descriptors

N N N N

N

N

N

N

NN

Application Model Abstract Syntax Tree

• Build model interpreters

• Generate descriptors in required (potentially different) declarative notation(s) for multiple platforms

• Ensure generated artifacts are:

• Syntactically valid

K. Balasubramanian et al, “Developing Applications Using Model-Driven Design Environments,” Computer, vol. 39, no. 2, pp. 33-40, Feb., 2006

Automate generation of platform-specific metadata from these abstractions

55

Challenge 2 Resolved: System Interface Evolution

2.Provide support for system interface evolution

• (Re-)Import/(Re-)Export IDL• Provides migration for

legacy systems• Eliminate accidental

complexities• Define platform interface

semantics using MetaGME & OCL constraints• e.g., a receptacle should

be connected to a facet of the same type or a type derived from the receptacle

K. Balasubramanian et al, “A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems,” Proceedings of the 11th IEEE Real-Time &

Embedded Technology & Applications Symposium, San Francisco, CA, March 2005

Provide automated support system interface & metadata evolution

56

Research ContributionsCategory Benefits Publications

Generative System Technologies

• Expressing domain constraints in the form of a platform-independent MDE tool

• Manage & automate the generation of syntactically valid metadata in various (potentially different) required declarative notations

1. Model Driven Engineering for Distributed Real-time & Embedded Systems, edited by Sebastien Gerard, Joel Champea, & Jean-Philippe Babau, Hermes, 2005

2. IEEE Real-Time & Embedded Technology & Applications Symposium, 2005

3. Elsevier Journal of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006

4. IEEE Computer, 2006

57

Expression of Design Intent: Proposed Enhancements

• Extend generative capabilities of PICML to .NET Web Services to generate:• Assembly manifests (.dll.manifest) –

Describes contents of a .NET component• Application manifests (.exe.manifest) –

Describes metadata associated with an application

• Application Configuration Files (app.config) – Describes application behavior configuration elements

• Web Service Configuration File (web.config) – Equivalent to app.config for external subsystems of a web Service

• Policy files ({enterprisesec, machine, security}.config) – Describes code access security policy elements

Policy

`

Group

Application Assembly Manifest

User

Component


Implementation

Properties


Component Assembly Configuration

Component Assembly Manifest

Application Assembly Configuration

Support development of heterogeneous systems

58

Proposed Enhancements: Evaluation Criteria• Baseline for comparison

• Deployment of a system having both CCM components & .NET Web Services with existing tools (vanilla CIAO, Visual Studio)

• Automate three-staged deployment of typical .NET Web services • Syntactically valid manifests for

the 3 stages: Development, Testing, & Production

• Eliminate errors in deployment due to inconsistent policies

• Eliminate need for user to write glue code to integrate a CCM component with a .NET Web Service

PICML (CCM)

PICML (.NET)

CCM Models

.NET Web Service Models

PICML (CCM+.NET)

GME Composition





CCM+.NET Web Service

Models

59





60


Manager

ScaleQosket

CropQosket

Compress Qosket



Predictor



Service)

Research Area 3: Application Specific Optimizations • Middleware tries to optimize

execution for every application

• Collocated method invocations

• Optimize the (de-)marshaling costs by exploiting locality

• Specialization of request path by exploiting protocol properties

• Caching, Compression, Various Encoding schemes, e.g. FOCUS tool-chain

• Reducing communication costs

• Moving data closer to the consumers by replication

• Reflection-based approaches

• Choosing appropriate alternate implementations

61


Component Middleware

Wang, N. et al, Applying Reflective Techniques to Optimize a QoS-enabled CORBA Component Model Implementation, 24th Annual International Computer Software & Applications Conference Taipai, Taiwan, October 2000.

Teiniker, E. et al, Local Components & Reuse of Legacy Code in the CORBA Component Model, EUROMICRO 2002, Dortmund, Germany (2002)

Diaconescu, A. & Murphy, J., Automating the Performance Management of Component-based Enterprise Systems through the Use of Redundancy, Proceedings of the 20th IEEE/ACM international Conference on Automated Software Engineering (Long Beach, CA, USA, November 07 - 11, 2005).

Gurdip Singh & Sanghamitra Das, Customizing Event Ordering Middleware for Component-Based Systems, pp. 359-362, Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC'05), 2005.

Web Services Gao, L et al, 2003, Application specific Data Replication for Edge Services, In Proceedings of the 12th International Conference on World Wide Web (Budapest, Hungary, May 20 - 24, 2003). WWW '03. ACM Press, New York, NY, 449-460.

Mukhi, N. K., 2004, Cooperative Middleware Specialization for Service Oriented Architectures, Proceedings of the 13th International World Wide Web Conference on Alternate Track Papers & Posters (New York, NY, USA, May 19 - 21, 2004).

62

Related Research: What’s missing?• Lack of high-level notation to guide

optimization frameworks

• Missing AST of application

N N N N

N

N

N

N

NN

Application Abstract Syntax Tree

63

Related Research: What’s missing?• Lack of high-level notation to

guide optimization frameworks

• Missing AST of application

• Emphasis on detection at run-time (reflection)

• Additional overhead in the fast path

• Not suitable for all systems

• Not completely application transparent

• Requires providing multiple implementations

• Optimization performed either

• Too early, or too late


Manager

ScaleQosket

CropQosket

Compress Qosket



Predictor



Service)

64




Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket




Stream 4

Stream 3

Stream 2

Stream 1

Application Specific Optimizations: Unresolved Challenges1.Lack of application

context• Missed middleware

optimization opportunities

• E.g., every invocation performs check for locality

• Optimization decisions relegated to run-time

• Impossible for middleware (alone) to predict application usage

• Settle for near-optimal solutions

Cannot be solved efficiently at middleware level alone!

Node Application

Container

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CH

Receptacle

Facet

Event Sink


Component Assembly



Creates

65




Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket




Stream 4

Stream 3

Stream 2

Stream 1

Node Application

Container

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CH

Receptacle

Facet

Event Sink


Component Assembly



Creates

2.Overhead of platform mappings

• Blind adherence to platform semantics

• Inefficient middleware glue code generation per component

• Example: Overhead of external components similar to internal ones

• Factory objects for internal components

3.Standard component models define only virtual assemblies

Need optimization techniques to build large-scale component systems!

Application Specific Optimizations: Unresolved Challenges

66




Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket




Stream 4

Stream 3

Stream 2

Stream 1

Node Application

Container

Factory

CHCH

CH

CH

CH

CH

Receptacle

Facet

Event Sink

Event Source

Component Home

Component Assembly


Optimized Invocation

Creates

CHCHCH

Proposed Approach: Supply Application Context w/Models1.Use models to capture &

derive application context

• Explicit, e.g., radar & sensor are collocated (user-specified)

• Implicit, e.g., radar & sensor deployed onto same node

• Detect components internal to an assembly

2.Optimize platform mappings

• Eliminate space overhead at system level

• e.g., eliminate creation overhead of homes for internal components

67

Proposed Approach: Physical Assembly Mapping3.Devise mapping for physical

component assembly

• Exploit hierarchy of application structure to fuse (make a component internal) at multiple levels in hierarchy

• Experimentally validate right depth of hierarchy to stop fusion

• Too deep – Single giant blob

• Too shallow – Potentially lower benefits

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

CH

68

Proposed Approach: Evaluation Criteria • Baseline for comparison

• Performance & footprint (with vanilla CIAO)

• Emergency Response System (30+ components)

• ARMS GateTest scenarios (1,800+ components)

• Scenario with & without inherent hierarchy

• Reduce static & dynamic footprint

• n = no. of internal components, x = total no. of components in the assembly

• Reduce no. of homes by (n-1)/x

• Reduce no. of objects registered with POA by (n-1)/x

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

Assembly Optimizer

Factory

CHCH

CH

CH

CH

CH CHCH

69

Proposed Approach: Evaluation Criteria • Improve performance

• t = no. of interactions between components within an assembly

• Transform t collocation checked calls to t unchecked calls

• Eliminate mis-optimizations• Check incompatible POA

policies• Incompatible invocation

semantics (oneway or twoway)

• No changes to individual component implementations• Eliminate need for a local

vs. remote version

• Customizable & application transparent• Investigate feasibility of applying

optimizations to .NET Web Services (in addition to CCM)

70





71

Summary of Research ContributionsTopic Benefits


Support static composition of systems by ensuring that the components get built correctly

Support dynamic composition of systems by ensuring that the connections between components are correct

Address composition scalability concerns by employing model-weaving technologies

Generative Technologies

Expressing domain constraints in the form of a platform-independent MDE tool

Manage & automate the generation of syntactically valid metadata in various required declarative notations

System Optimization Technologies

Automatic discovery & realization of optimizations from models using application context; such optimizations are impossible to perform if operating at the middleware layer alone.

Propose a novel mechanism for mapping an assembly as a component without any extra overhead

Component Assembler

Component Assembly

Component Component

Component Component

Component Package

Component Assembly

Component Component

Component Component

Component Assembly

Component Component

Component Component

(1)

Inte

rfa

ce

De

finiti

on





Component Developer

Component Packager

ComponentDeployer

PICMLcompositio

n

asse

mbl

y

optimization

gene

ratio

n

specification

Assembly

Deployment

Assembly

Assembly

DAnCE Framework

Component


Implementation

Properties


Component Assembler

Component Assembly

Component Component

Component Component

Component Package

Component Assembly

Component Component

Component Component

Component Assembly

Component Component

Component Component

(1)

Inte

rfa

ce

De

finiti

on





Component Developer

Component Packager

ComponentDeployer

PICMLco

mposition

asse

mb

ly

optimization

gene

ratio

n

specification

Assembly

Deployment

Assembly

Assembly

DAnCE Framework

Component


Implementation

Properties


Component Assembler

Component Assembly

Component Component

Component Component

Component Package

Component Assembly

Component Component

Component Component

Component Assembly

Component Component

Component Component

(1)

Inte

rfac

e D

efin

ition





Component Developer

Component Packager

ComponentDeployer

PICMLco

mposition

asse

mbl

y

optimization

gene

ratio

n

specification

Assembly

Deployment

Assembly

Assembly

DAnCE Framework

Component


Implementation

Properties


72

Summary of PublicationsCategory Publications

Generative System Technologies

1. A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems, 11th IEEE Real-Time & Embedded Technology & Applications Symposium, San Francisco, CA, March 2005.

2. Developing Applications Using Model-Driven Design Environments, Computer, vol. 39, no. 2, pp. 33-40, Feb., 2006.

3. Model-driven Development of Component-based Distributed Real-time & Embedded Systems, Model Driven Engineering for Distributed Real-time & Embedded Systems, Hermes, 2005.

4. Model Driven Middleware: A New Paradigm for Deploying & Provisioning Distributed Real-time & Embedded Applications, Elsevier J. of Science of Computer Programming: Special Issue on Model Driven Architecture, 2006.


1. Towards Composable Distributed Real-time & Embedded Software, Proceedings of the 8th IEEE Workshop on Object-oriented Real-time Dependable Systems (WORDS), Guadalajara, Mexico, January 2003.

2. Applying Model-Driven Development to Distributed Real-time & Embedded Avionics Systems, the International Journal of Embedded Systems, special issue on Design & Verification of Real-Time Embedded Software, April 2005.

3. A Platform-Independent Component Modeling Language for Distributed Real-time & Embedded Systems, Elsevier J. of Computer & System Sciences, 2006.

4. Weaving Deployment Aspects into Domain-Specific Models, International J. on Software Engineering & Knowledge Engineering, Summer 2006 (Accepted).

First Author Second Author

73

Doctoral Research & Dissertation Timeline

Non-generated artifact

To be implemented

Implementation complete

Collaboration with Jeff Parsons

9 Jan, 2003 15 Dec, 2006

3/03 6/03 9/03 12/03 3/04 6/04 9/04 12/04 3/05 6/05 9/05 12/05 3/06 6/06 9/06

1/03WORDS 03 Paper

7/03Work on PICML started

4/04Inital version of PICML

10/03Elsevier Journal 06 Paper

6/04Support for generation of metadata

8/04Support for hierarchical composition

9/04RTAS 05 Paper

5/05Elsevier Journal 06 Paper

12/04IJES 05 Paper 3/05

IJSEKE 06 Paper

1/05MDE Book Chapter 05

10/05IEEE Computer 06

2/05Support for scalable composition

10/04OOPSLA 04 Poster

10/06Support for .NET Web Services

4/06 - 9/06Submissions to MoDELS, Middleware,

OOPSLA/GPCE, DOA, RTSS, ICSE

3/06Qualifying Exam

7/06Support for assembly optimization

74

Concluding Remarks

• Component middleware is an emerging paradigm

• Crucial to realizing the vision of Software Factories

• Problems with component middleware

• Significant gaps in the development & integration toolchain

• Potential to negate benefits of using component middleware

• Direct application to DRE systems not possible

• Might not meet the stringent QoS requirements of DRE systems

• My research

• Resulted in improved tool-support for component middleware

• Model-Driven Engineering toolchain

• Successful transition to DD(X) program for TSCEI deployment & configuration services

• Proposes to perform optimizations on component middleware that were previously infeasible

• Exploit application context made available by MDE tool-chain

Tools can be downloaded from www.dre.vanderbilt.edu/CoSMIC/

model-driven engineering of component systems vanderbilt university nashville, tennessee institute...

Documents

alternate views

language java

robust distributed systems

java rmi

c andor platform com

corba component model

robust software

oo techniquesresult