model-driven engineering of component systems

Model-Driven Engineering Of Component Systems

Vanderbilt University Nashville, Tennessee

Institute for Software Integrated Systems

Krishnakumar BalasubramanianJames Hill

Dr. Douglas C. Schmidt{kitty,

hillj,jules,schmidt}@dre.vanderbilt.edu

2

Presentation Roadmap• Research Challenges

• Software System Analysis • Component System Integration • Component System Optimization

• Demonstration Section • Scenario• Question• Capability Demo• Enabling Technology

• Concluding Remarks• December Demo• Benefits & Roadmap

3

Model-Driven Engineering Technologies

Component configurator(4

) con

figur

es

CoSMIC

packagingas

sem

bly

specification

configuration

plan

ning

feedback

Component Developer

Component

ResourceRequirements

Impl

Impl

Impl

Properties

(1) d

evel

ops

Component Assembler

Component Assembly

Component Component

Component Component

(2) assembles

Component Package

Component Assembly

Component Component

Component Component

Component Assembly

Component Component

Component Component

Component packager

(3) packages

Component deployer

(5) deployment planningAssembly

DeploymentApplication

Assembly

Assembly

(7) feedback to

configuration &

planning

Analysis & Benchmarking

systemanalyzer

(6) analysis & benchmarking

System Optimization Technologies

System Analysis

Technologies

System Integration

Technologies

4

SLICE System Scenario (1/2)

SLICE application string consists of: 2 sensors 2 planners that process data from the

sensors Configuration component responsible

for converting planner output into configuration input for effectors

Effectors that perform action based on configuration parameters

sensor 2

sensor 1(main)

planner 1 planner 2

configuration

error recovery

effector 2

effector 1(main)

5

SLICE System Scenario (2/2)

Deployment & Performance Requirements

• Critical path deadline is 350 ms• main sensor to main effector

through configuration • Components in the critical path must

be deployed across multiple hosts• Main sensor & effector must be

deployed on separate hosts

• Three hosts• One database is shared between

all hosts

sensor 2

sensor 1(main)

planner 1 planner 2

configuration

error recovery

effector 2

effector 1(main)

6

Software System Analysis Challenge: Serialized Phasing

Application components

developed after infrastructure is

mature

Development Timeline

Level of

Ab

stra

ctio

n

System infrastructur

e components developed

first

7



Level of

Ab

stra

ctio

n

Integration Surprises!!!

System integration & testing

Finished development

8



Level of

Ab

stra

ctio

n

Still in development

Ready for testingComplexities• System infrastructure cannot be

tested adequately until applications are done

9



Level of

Ab

stra

ctio

n

Overall performance?

Complexities• System infrastructure cannot be

tested adequately until applications are done

• Entire system must be deployed & configured properly to meet QoS requirements

• Existing evaluation tools do not support “what if” evaluation

10


Meet QoS requirements?

Key QoS concerns• Which deployment configurations

meet the QoS requirements?


Level of

Ab

stra

ctio

n

11


Performance metrics?


meet the QoS requirements? • What is the worse/average/best

time for various workloads?


Level of

Ab

stra

ctio

n

12


It is hard to address these concerns in processes that use serialized phasing


meet the QoS requirements? • What is the worst/average/best time

for various workloads?• How much workload can the

system handle until its QoS requirements are compromised?

System overload?


Level of

Ab

stra

ctio

n

13

Software System Analysis in 10 Years

EnsureDesign

Conformance

ValidateDesignRules

Conduct “What If”Analysis

Validate Design Rules

• System will adhere to system design specifications

• “Correct-by-construction”

Ensure Design Conformance

• System will be deployed & configured to conform to system design rules

Conduct “What If” Analysis

• QoS concerns can be analyzed prior to completing the entire system

• e.g., before system integration phase

The cycle is repeated when developing application & infrastructure components

14

Software System Analysis in 3 Years

•Develop MDE tools which allow emulation of real components on target infrastructure

•Develop analysis tools to evaluate & verify QoS performance

•Develop framework to allow instrumentation of “real” components

•Develop framework for intermixing of emulation components with “real” component

ValidateDesignRules

Enable testing on target infrastructure early in development lifecycle

Component Workload Emulator (CoWorker) Utilization Test Suite Workflow (CUTS):

ValidateDesign

Conformance

Conduct“What If”Analysis

15

Software System Analysis 2006 Demos

• August• Model-Driven Software System Analysis Tools• Automated generation of emulation components

• December• Develop CoWorkEr emulation framework in multiple SOA

technologies• Microsoft .NET web services• J2EE web service

• Integration of CBML & WML into other MDD tools• GEMS

16

How can system engineers analyze the performance of an application on the actual deployment

environment before the development of application components is complete?

Software System Analysis Motivating Question?

17

Enabling Technology: Model-Driven Software System Analysis

• The Component Behavior Modeling Language (CBML) & Workload Modeling Language (WML) is used to define the behavior of CoWorkEr components in a PICML model

• CoWorkEr implementation is generated on top of a component framework that contains a benchmarking aspect

Emulation Framework

18

Component System Integration• System refers to software systems built

using• Service-Oriented Architecture (SOA)

technologies like Web Services• Component middleware technologies

like Enterprise Java Beans (EJB), CORBA Component Model (CCM)

• Integration can be done at multiple levels• Process Integration• Functional Integration• Data integration• Presentation Integration• Portal Integration

• System Integration refers to functional integration done via

• Distributed Object Integration• Service-Oriented Integration

QoSProperties

Checksum

Version Dependencies

List of FilesQoS Specs ComponentInterconnections

ImplementationDLL DLL

QoSProperties

Checksum



19

Component System Integration: Unresolved Challenges• Component middleware is getting a lot

more declarative• Management of diverse metadata

& configuration of middleware is proving to be error-prone

• Current practice attempts integration in a manual fashion

• Inappropriate level of abstraction• Integrators need to learn enough of

every technology• Lack of automated tools limits

scalability of integration• Total system performance determined

by “Quality-of-Integration” (QoI)• QoI refers to the effect of the

integration on the functional & QoS properties of the integrated system

• Along with “Quality-of-Implementation”

<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

20

Component System Integration: Unresolved Challenges• Lack of tool support for key integration

activities• Needed to scale up the integration &

deployment process• Relieve the system integrator from

ever-changing platform-specific details aka “accidental complexities”

• Unable to define constraints at the whole system level

• Needed to evaluate service-level agreements before integration

• Check system consistency before & after integration

• Lack of infrastructure to apply system level optimizations

• Needed to automate and optimize the generated glue-code

• (Re-)Target emerging & new middleware technologies

QoSProperties

Checksum


List of FilesQoS Specs ComponentInterconnections


QoSProperties

Checksum



21

Component System Integration in 10 Years

Tools to integrate “systems-in-the-large”

• Provide abstractions for expressing system level design intent

• Automation of key system integration activities

• Generation of integration glue-code

• Generation of middleware & deployment metadata

• Integrated system satisfies Service Level Agreements (SLAs)

• De-emphasize programming-in-the-small

• No more whack-a-mole approach to system integration

• No more violation of Don’t Repeat Yourself (DRY) principle

22

Component System Integration in 3 Years•Develop tools to allow functional integration of two sample COTS technologies

•CCM•Web Services

•Express & evaluate service level agreements between applications built using

•CCM•Web Services

•Enable integrators to evaluate QoI using different

• Integration topologies, e.g., Message Bus, Point-to-Point, Broker (Indirect/Direct), Publish/Subscribe

• Integration architectures, e.g., Java Business Integration (JBI), Service Component Architecture (SCA), Windows Communication Foundation (WCF)

System Integration Modeling Language (SIML)

PICML (CCM DSML)

WSML (WS DSML)

CCM Deployment descriptors

Web Service Deployment descriptors

23

Component System Integration 2006 Demos• August

• Use CCM & Web Service as sample technologies to be integrated

• Show automatic generation of Web Service implementation from model

• December• To be defined in discussion with LMCO STI personnel

24

Component System Integration Motivating Questions?

1. How do you integrate systems that were not designed to work together?

2. How do you predict the effects of system integration before the actual integration?

3. How do you automate key system integration activities?

25

Demonstration Scenario

Web Service Client

CCM Client

Benchmark_Data_Collector Web Service

TypeSpecific IIOP ó SOAP

SOAP Server

CCMClient

26

Enabling Technology: Model-Driven System Integration• Model-based approach to system

integration• Develop System Integration

Modeling Language (SIML), a DSML for system integration

• Hierarchical composition of DSMLs• Composed from multiple sub-DSMLs

• PICML CCM • WSML Web Services• Each sub-DSML is used as a

model library• Built in a re-usable & extensible

fashion • “Open-Closed” principle• New languages can be added;

existing ones reused• Preserve existing investment

• Tools for sub-DSMLs work seamlessly in composite DSML


PICML (CCM DSML)

WSML (WS DSML)



27

Enabling Technology: Usage Scenarios• SIML consists of DSMLs for each

technology being integrated• Targets system developers &

integrators• System Developers

• Use DSML of corresponding technology

• Assists in automating key deployment activities

• Used during development of individual sub-systems

• System Integrators• Use the integration DSML • Assists in combining sub-

systems together• Used during integration testing

of the whole system


PICML (CCM DSML)

WSML (WS DSML)



28

Control Center SystemResource

Manager

ScaleQosket

CropQosket

Compress Qosket

LocalResourceManager

Cropping QoSPredictorScaling QoS

Predictor

Compression QoSPredictor

Image Feeds (.NET Web

Service)

Component System Optimization• 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

• Reducing communication costs

• Moving data closer to the consumers by replication

• Reflection-based approaches

• Choosing appropriate alternate implementations

29

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

Component System 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

Event SourceComponent Home

Component Assembly

Component Remote Invocation

Collocated Invocation

Creates

30




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

Event SourceComponent Home

Component Assembly


Collocated Invocation

Creates

2.Overhead of platform mappings

• Blind adherence to platform semantics

• Inefficient middleware glue code generation per component

• Example: Every component is created using a Factory Object

• Overhead of external components similar to internal ones

3.Standard component models define only virtual assemblies

Component System Optimizations: Unresolved Challenges

31

Component System Optimization in 10 Years• Generate application

specific components for a product-line architecture

• Optimize middleware in an application-specific fashion

• Improve performance

• Reduce static & dynamic footprint

• Eliminate mis-optimizations

• No changes to individual component implementations

• Customizable & completely application transparent

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

Assembly Optimizer

Factory

CHCH

CH

CH

CH

CH CHCH

32




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

Component System Optimization in 3 Years• Identify sources of overhead in

large-scale component-based system of systems

• Develop component assembly optimizer which eliminates these sources of overhead

• Use CORBA Component Model as a test bed

• Apply optimization technology to a variety of scenarios

• PCES Emergency Response System (30+ components)

• ARMS GateTest scenarios (100+ components)

• Scenarios with & without inherent hierarchy

33

Component System Optimization Motivating Question?

How do you custom optimize individual component implementations based on the

global system composition properties & usage scenario without requiring any changes to the

component implementation?

34

Component System Optimization: December Demo• Baseline for comparison

• Performance & footprint (with vanilla CIAO)

• Emergency Response System (30+ components)

• ARMS GateTest scenarios (100+ components)

• Scenario with & without inherent hierarchy

• Reduce static & dynamic footprint

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

• Reduce from n factories to 1 factory

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

Assembly Optimizer

Factory

CHCH

CH

CH

CH

CH CHCH

35

Component System Optimization: December Demo• 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 Web Services (in addition to CCM)

36

Concluding Remarks• Our research focuses on Model-driven Engineering (MDE) solutions

• Software System Analysis Tools (CUTS/PICML/WSML)

• Benefits

• Reduces complexities with serialized phasing in large-scale systems

• Automates generation of distributed emulation infrastructure

• Component System Integration Tools (SIML)

• Benefits

• Provides infrastructure to evaluate service level agreements

• Automates generation of integration glue-code

• Component System Optimization Tools (PICML/WSML)

• Benefits

• Perform optimizations on a “system-of-systems” scale

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

37

Enabling Technology: Component Assembly Optimizer• Component Assembly Optimizer

• Uses system models as input• Combines

• Information about the system-as-a-whole as well as individual components from the model

• Catalog of (feature, perf. overhead),(feature,dependent features) & (feature, incompatible features) tuples of the underlying middleware technology

• To optimize globally, i.e., across the whole “system-of-systems”, the

• Generated middleware glue code• Configuration of underlying

middleware• Generated deployment metadata

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

Assembly Optimizer

Factory

CHCH

CH

CH

CH

CH CHCH

38

Target Scenarios• “System of Systems” with

portions exhibiting• Hierarchy• No hierarchy

• Built using COTS component/SOA technologies

• Web Services• CCM• EJB

• Specific deployment scenario• Information about

• Composition structure of systems/component assemblies

• Desired QoS policies• Target deployment

domain

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

39

Solution 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

Assembly Optimizer

40

Component System Optimization: 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

41

• 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

Control Center SystemResource

Manager

ScaleQosket

CropQosket

Compress Qosket


Cropping QoSPredictorScaling QoS

Predictor

Compression QoSPredictor

Image Feeds (.NET Web

Service)

Component System Optimization: What’s missing?

42

Steps Involved in Integration Using SIML1.Generate a CCM DSML model

from the IDL definition of application components

2.Generate a WSDL file from the IDL of the component(s) to be exposed as Web Service(s)

3.Import the CCM model into integration DSML; define connections between CCM components to assemble application

4.Generate a WSDL DSML model from generated WSDL

5.Import the Web Service model into integration DSML

Integration DSML

CORBA Component

Model DSML

Web Services DSML



CORBA Component Application

IDL 2 WSDL Generator

1

IDL 2 PICML Generator

WSDL Importer

Web Service Client

Web Service Client

Web Service Client


SOAP Server

CCMClient

CCM Component

2

3

4

5

8

97

6

43

Steps Involved in Integration Using SIML6.Annotate the WSDL model to

specify deployment information like WSDL port bindings (host name, host port number, URI including namespace of service et al.

7.Generate CCM deployment descriptors

8.Generate the type-specific proxies, i.e., integration glue-code

9.Generate Web Service deployment descriptors including updated WSDL, web container hosting artifacts

Integration DSML

CORBA Component

Model DSML

Web Services DSML



CORBA Component Application

IDL 2 WSDL Generator

1

IDL 2 PICML Generator

WSDL Importer

Web Service Client

Web Service Client

Web Service Client


SOAP Server

CCMClient

CCM Component

2

3

4

5

8

97

6

44

SIML Benefits• Develop integration DSML in a

modular & extensible fashion• Model-library based approach• Allows re-use of existing

platform DSMLs• New platforms can be added

easily

Integration DSML

CORBA Component

Model DSML

Web Services DSML



Web Service Client

Web Service Client

Web Service Client

Generic IIOP ó SOAP

SOAP Server

CCMClient

CCM Component

Web Service Client

Web Service Client

Web Service Client


SOAP Server

CCMClient

CCM Component

model-driven engineering of component systems

Documents

system overload

system handle

doneentire system

serialized phasingstill

serialized phasingit

configuration components

configuration input

various workloads