Model-Driven Engineering of Component Middleware-based Systems Vanderbilt University Nashville,...

Model-Driven Engineering of Component Middleware-based

Systems

Vanderbilt University Nashville, Tennessee

Institute for Software Integrated Systems

CS WithIT Seminar, April 26th, 2007

Krishnakumar [email protected]

www.dre.vanderbilt.edu/~kitty

2

Model-Driven Engineering Approach

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

• System Optimization Technologies – System optimization infrastructure• Generation Technologies – Metadata generation infrastructure• System Integration Technologies – System Integration using model

composition

Generation Technologies

System Composition Technologie

s

System Optimization Technologie

s

System Integration

Technologies

3

Presentation Road Map

• Technology Context• Overview of Research Challenges• Research Area 1: Component System

Integration • Research Area 2: Application-Specific

Optimizations• Summary of Research Contributions• Concluding Remarks

4

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)

5





6

Component System Development Challenges• Lack of system composition tools

Component

ResourceRequirements

Impl Impl Impl

Properties

Component Assembly

ComponentComponent

ComponentComponent

7


• 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

8



• 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

9




• Need to integrate with systems built using heterogeneous middleware

10

Component System Development Challenges

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

• Lack of system composition tools



• Need to integrate with systems built using heterogeneous middleware

• 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

11

Solution Approach: PICML & SIML

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

• System Optimization Technologies – System optimization infrastructure• Generation Technologies – Metadata generation infrastructure• System Integration Technologies – System Integration using model

composition


System Composition Technologie

s

System Optimization Technologie

s

System Integration

Technologies

12





Research Area 1: Component System Integration• Integration can be done at multiple levels

• Process Integration• Functional Integration• Data integration• Presentation Integration• Portal 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)

• System Integration refers to functional integration done via

• Distributed Object Integration• Service-Oriented Integration

13

Related Research

14

Category Related Research

Integration Evaluation Tools

IBM’s WebSphere

Smith, C., & Williams, L. (2001). Performance Solutions

Integration Design Tools

Object Management Group. UML Profile for Enterprise Application

Integration (EAI), omg document formal/04-03-26 edition, March 2004.

Integration Patterns

G. Hohpe and B. Woolf. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, October 2003.

Resource Adapters

Java Messaging Specification & J2EE Connector Architecture

IBM’s MQSeries (IBM, 1999), Microsoft BizTalk Server

Integration frameworks

Web Ontology Language. www.w3.org/2004/OWL/, Feb 2004.

Ian Foster, C. Kesselman, J. M. Nick, and S. Tuecke. Grid Services for Distributed System Integration. Computer, 35(6):37–46, 2002

L. Zeng, B. Benatallah, A. H. Ngu, M. Dumas, J. Kalagnanam, and H. Chang. QoS-Aware Middleware for Web Services Composition. IEEE Trans. Softw. Eng., 30(5):311–327, 2004

Integration Quality Analysis

H. Ludwig, A. Keller, A. Dan, R. P. King, and R. Franck. Web Service Level Agreement Language Specification. http://researchweb.watson.ibm.com/wsla/documents.html, January 2003.

Related Research: What’s missing?• Integration Evaluation Tools

• Serve only the preliminary stage

• Integration Design tools• Not integrated with

deployment• Integration Patterns

• Offer best practices (only)• Resource Adapters

• Still require manual “integration programming”

• Integration frameworks • Rely on unambiguous, formal

representations of capabilities

• Not always feasible with legacy systems

15

GatewayComponent

GatewayComponent

NamingServiceNamingService

LoggingComponent

LoggingComponent

CoordinatorComponentCoordinatorComponent

DatabaseComponentDatabase

ComponentIdentity

ManagerIdentity

ManagerBusiness

LogicBusiness

Logic

Client A

Client B

component Logging_Service{provides Logger handle;consumes LogEvent log_event;

};

component Logging_Service{provides Logger handle;consumes LogEvent log_event;

};

WS-Log Analyzer

Log Analyzer

Logging Web Service

SOAP Server

CCM Client

TypeSpecific IIOP ó SOAP

Motivating Application• Enterprise Distributed System

• Different client applications• Differentiated services to

clients• System Domain

• Shipboard Computing • On-demand situation

awareness• Integration with human

operators• Logging Component

• Originally built using CORBA Component Model (CCM)

• Needed to be exposed as a Web Service

• Integrate with Log Analyzer built as Web Service Clients

16

Component System Integration: Unresolved Challenges(1/5)1. Choosing an appropriate level

of integration• Need to select elements from

the different technologies• Selection Challenges

• Number of normalizations• To/from native types

• Flexibility of deployment• In-process/Out-of-

process• Evolving the integration

architecture• Increasing the number

of peers integrated• Availability of platform-

specific infrastructure • OS, languages

17

System Integration

CORBA Component

Model Subsystem

Web Services Subsystem

Required Interface

Provided Interface

Event Source

Event Sink

Component

2. Reconciling differences in interface specifications

• Datatype Mapping• e.g., CORBA IDL to Web

Services WSDL• Exception Mapping

• e.g., SOAP faults to CORBA Exceptions

• Language Mapping• Different source/target

implementation languages• Limited scope at level of

functional integration • Restricted to out-of-

process IPC

18

component Benchmark_Data_Collector { provides Testing_Service testing_service;

provides BDC_Control_Handle controls;

attribute long timeout;

attribute string service; };

<wsdl:service name="CUTS.Benchmark_Data_Collector"> <wsdl:port name="CUTS.Benchmark_Data_Collector.online_measurements" binding="tns:CUTS.Benchmark_Data_Collector._SE_online_measurements"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> <wsdl:port name="CUTS.Benchmark_Data_Collector.controls" binding="tns:CUTS.Benchmark_Data_Collector._SE_controls"> <soap:address location="http://localhost:8080/" wsdl:required="false"/> </wsdl:port> </wsdl:service>

Component System Integration: Unresolved Challenges(2/5)


Java Web Service Client

C# Web Service Client

TypeSpecific IIOP ó SOAP

SOAP Server

CCMClient

CCM Component

3. Managing differences in implementation technologies• How to map low-level technology details such as networking,

discovery?• Protocol differences

• e.g., Internet Inter-ORB Protocol (IIOP) in CCM vs. SOAP in Web Services

• Discovery services differences• e.g., CORBA Naming Service vs. UDDI repositories

• Quality of Service (QoS)• Ensure service-level agreements are met

19

Component System Integration: Unresolved Challenges(4/5)4. Managing deployment of

subsystems• Declarative notations used to

capture various configuration options

• e.g., CCM deployment descriptors, .NET assembly manifests

• Functionality of system depends on correct configuration of metadata

• Development-time default values different from production values

• e.g., configuration of Web Servers hosting Web Services

20

CCM Subsystem

QoS Properties

Checksum

Version Dependencies

List of FilesQoS Specs Component Interconnections

CCM ImplementationDLL DLL

Web Services Subsystem

QoS Properties

Checksum


Web Services ImplementationDLL DLL


5. Interoperability issues• Multiple implementations of same middleware technology• Differences between implementations

• e.g., Java Web Services stack vs. .NET Web Services stack• Problems show up only during system integration

• e.g., existence of standards like Web Services-Interoperability (WS-I)

• Need to deal with interoperability issues in a less than ideal world21

Component DSML A

Component DSML B

DSML A Models

DSML B Models

Composite DSML

Model Composition

Imported Entity

22

Solution Approach: (Meta-) Model Composition• System Integration using (Meta-)

Model composition• Hierarchical composition of multiple

domain-specific modeling languages(DSMLs)

• Each corresponding to the different middleware technologies (domains)

• Built in a reusable & extensible fashion

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

existing ones reused• Semantics of existing DSMLs

preserved in composition• Refinement of semantics

allowed

System Integration Modeling Language (SIML)• Prototype implementation of

(Meta-) model composition• Composed from two domain-

specific Modeling Languages (DSMLs)

• CCM Platform-Independent Component Modeling Language (PICML)

• Web Services Web Services Modeling Language (WSML)

• Supports integration of applications built using CCM and Web Services

23

System Integration Modeling Language (SIML)

PICML (CCM DSML)

WSML (WS DSML)

CCM Deployment descriptors

Web Service Deployment descriptors

Required Interface

Provided Interface

Event Source

Event Sink

CCM DSML

Web Services DSML

CCM Models

Web Service Models

System Integration

DSML

Model Composition





Integration Glue code

Imported Entity

Exported Entity

24

System Integration Evaluation Criteria1. Seamless support for existing

tools• Existing investment in tools

should be preserved2. Integration architecture should

evolve with changes to the applications

• Changes to applications shouldn’t require a lot of rework

3. Preserve application encapsulation

• Individual applications should be shielded from changes in other applications

4. Existing semantics should be preserved

• Semantics of stand-alone applications should be preserved

25

Evaluating System Integration using SIML1. Representation of independent

concepts• PICML & WSML model

interpreters work seamlessly in SIML

• Allows Import/Export of both PICML and WSML models

2. Supporting model evolution• PICML & WSML packaged as

read-only model libraries• Changes to either propagated

through library refresh3. Partitioning model namespaces

• PICML & WSML assigned separate namespaces

4. Handling constraints• Namespaces provide

appropriate context for constraint evaluation

System Integration Modeling Language

PICML WSML

Component

Port

Service

BindingPort

HttpsBinding

Service

BindingPort

1

2

3

4

SIML satisfies the evaluation criteria for system integration

Resolving Challenge 1 : Choosing Integration Level• Combination of pre-defined

& customizable integration levels

• Pre-defined interactions• CCM Ports Web

Service Ports• User-defined interactions

• Component level• Assembly level

• SIML defines new interactions between CCM ports and Web Services ports

• Allows integration of other middleware technologies

• e.g., Enterprise Java Beans

26


Web Services Modeling Language

Platform-Independent Component Modeling Language

CCM Component

Gateway

Identity Manager

Business Logic

Naming Service

Coordinator

Database

Logging Logging

Java Log Analyzer

C# Log Analyzer

Log Analyzer

Web ServiceWeb Service Client

SIML allows representing integration architecture at the model level

Resolving Challenge 2: Reconciling Differences in Interfaces• SIML provides a set of tools

idl_to_wsdl, idl_to_picml, WSDLImporter

• Both IDL and WSDL can be directly imported into models

• Performs datatype mapping• Maps CORBA datatypes

to WSDL datatypes• Performs exception mapping

• Maps CORBA exceptions to WSDL faults

• Limited language mapping • Maps ISO/ANSI C++ to

Microsoft C++/CLI

27




CCM Component

Gateway

Identity Manager

Business Logic

Naming Service

Coordinator

Database

Logging Logging

Java Log Analyzer

C# Log Analyzer

Log Analyzer






idl_to_picml.exe

idl_to_wsdl.exe

WSDLImporter.exe


SIML’s interface mapping automatically handles differences in interfaces

Resolving Challenge 3: Handling Implementation Differences• Resource Adapters are

typically used to bridge implementation differences

• SIML implements resource adapters via Gateways

• Automatically generates gateways from models

• Perform protocol mapping• IIOP SOAP mapping

• Perform discovery mapping• Connects to CORBA

Naming Service• Configurable Gateway

generation from models• GSOAP, Microsoft .NET

Web Services

28




CCM Component

Gateway

Identity Manager

Business Logic

Naming Service

Coordinator

Database

Logging Logging

Java Log Analyzer

C# Log Analyzer

Log Analyzer

TypeSpecific Gateway IIOP ó SOAP

GatewayGenerator.exe


SIML generates integration glue-code directly from the application models

Resolving Challenge 4: Managing Heterogeneous Deployment• Deployment of sub-systems

requires different mechanisms

• SIML can use existing tools for individual sub-system deployment

• Possible because of model composition

• Deployment metadata configuration & generation

• Directly from within SIML

• CCM• DeploymentPlan.exe

• Web Services• WSDLExporter.exe

29





CCM Component

Gateway

Identity Manager

Business Logic

Naming Service

Coordinator

Database

Logging Logging

Java Log Analyzer

C# Log Analyzer

Log Analyzer


WSDLExporter.exe

DeploymentPlan.exe


SIML provides an integrated view of heterogeneous deployment

Resolving Challenge 5: Handling Interoperability Differences• Knowledge of sub-DSML

technologies built into SIML• Allows compensating for

interoperability differences• idl_to_wsdl.exe

• Maps IDL to WS-I defined subset of WSDL

• GatewayGenerator.exe• Inter-operable subset of

RPC encoding• WSDLExporter.exe

• Interoperable XML namespaces in WSDL

• Newly discovered incompatibilities can be worked around

30





CCM Component

Gateway

Identity Manager

Business Logic

Naming Service

Coordinator

Database

Logging Logging

Java Log Analyzer

C# Log Analyzer

Log Analyzer







TypeSpecific Gateway IIOP ó SOAP

idl_to_picml.exe

idl_to_wsdl.exe

WSDLImporter.exe

WSDLExporter.exe

DeploymentPlan.exe

GatewayGenerator.exe


SIML codifies inter-operability workarounds

31

Summary of Research ContributionsCategory Benefits Publications

System Integration Technologies

• System integration from the high-level abstraction of models

• Model-composition allows preserving investment in existing domain-specific languages

• Relieves system integrators from dealing with intricacies of heterogeneous middleware technologies by automatically generating integration glue code

1. IEEE Engineering of Computer-Based Systems, 2007

2. Designing Software-Intensive Systems: Methods and Principles, Bookchapter Edited by Dr. Pierre F. Tiako, Langston University, OK. (Accepted for publication)

32





33

Control Center SystemResource

Manager

ScaleQosket

CropQosket

Compress Qosket

LocalResourceManager

Cropping QoSPredictorScaling QoS

Predictor

Compression QoSPredictor

Image Feeds (.NET Web

Service)

Research Area 2: 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

• Reducing communication costs

• Moving data closer to the consumers by replication

• Reflection-based approaches

• Choosing appropriate alternate implementations

34

Related ResearchCategory Related Research

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

35

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

36

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)

37

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

Node Application

Container

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CHCH

CH

Receptacle

Facet

Event Sink


Component Assembly

Component Remote Invocation

Collocated Invocation

Creates

1. Overhead of platform mappings

• Blind adherence to platform semantics

• Inefficient middleware glue code generation per component

• Example:

• Creation of a factory object per component

• Servant glue-code generation for every component

Need optimization techniques to build large-scale component systems!

Application Specific Optimizations: Unresolved Challenges

Solution Approach: Component Assembly Optimizer

38

PICMLmodel

CH CH

CHCH

OS KERNEL

OS I/O Subsystem

Network Interfaces

MIDDLEWARE

Component Assembly Optimizer

Deployment Plan

Configuration Files

CH

Required Interface

Provided Interface

Event Sink


Component Assembly

Component Invocation

Creates

CH

CH

CH

CH

CH

CH

CH

CH

CH CH

CHCH

• Component Assembly Optimizer

• Uses the application model as the input

• Exploits knowledge about platform semantics to rewrite the input model to a functionally equivalent output model

• Generates middleware glue-code

• Generates deployment configuration files

• Operates just before deployment

• Can be viewed as a “deployment compiler”

Component Assembly Optimizer Inputs• Set of 3 input graphs

• G1: (V1, E1) where V1 is the set of components in the application & E1 is the set of connections between them

• G2: (V2, E2), where V2 is the union of vertices in V1 with the set of QoS configuration options on components & E2 is the set of associations between the components and the QoS options

• G3: (V3, E3), where V3 is the union of vertices in V1 with the set of nodes in the target deployment domain of the application & E3 is the set of associations between the components and the nodes of the domain

39

Component Assembly Optimizer Output

40

• Produces an output graph

• Go: (Vo, Eo), where Vo is the set of composites (physical assemblies) created on a single node, & Eo is the set of connections between the composites

• Creation of physical assemblies subject to a number of constraints

• Average case

• |Vo| < |V1|

• Worst case

• |Vo| = |V1|, i.e., the optimizer couldn’t create any physical assemblies

• Equivalent to deployment of original application

Physical Assembly

41

• Physical Assembly

• Created from the set of components that are deployed within a single process of a target node

• Subject to various constraints

• Example constraints include

• No two ports of the set of components should have the same name

• No two components should have incompatible RT-CORBA policies

• No change to individual component implementations

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

Physical Assembly Generation

42

• Given set of components deployed on a single process of a target node

• Compute pair-wise intersections of component port name sets

• If intersection is null, merge the two components into a physical assembly

• Supported interfaces of constituent components are supported by physical assembly

• Additional RT-CCM constraint

• If intersection is null & RT-CORBA policies of the components are compatible

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

Middleware Concepts Exploited by Physical Assemblies

43

• Opacity of object references

• Components don’t rely on specific details of object references, e.g., location of type information

• Allows replacing references transparent to component implementations


44




• Presence of a component context

• Components access ports of other components using a context object

• Allows replacing context transparent to component implementations

Container

Servant

ComponentSpecificContext

CCMContext

MainComponent

Executor

ExecutorsExecutorsExecutors

POA

EnterpriseComponent

CCMContext

Container

Servant

ComponentSpecificContext

CCMContext

MainComponent

Executor

ExecutorsExecutorsExecutors

POA

EnterpriseComponent

CCMContext

user implemented

code

Container

CORBAComponen

t

POA

Ext

erna

lI n

t erf

ac e

s

InternalInterface

s


45




• Presence of a component context

• Components access ports of other components using a context object

• Allows replacing context transparent to component implementations

• Clean separation between glue-code & component implementation

• Allows modifications transparent to component implementations

Technique can be applied to other middleware with these properties

Stub

Executors

Skel

IDL Compiler

IDL

CIDL

CIDL Compiler

Executor IDL

Servants

ExecutorStubs

IDL Compiler

XMLComponentDescriptors

46

Physical Assembly Evaluation Criteria • Footprint of physical assembly

components

• Compared to vanilla Component-Integrated ACE ORB (CIAO)

• Different scenarios

• Simple scenarios (<= 10 components)

• ARMS GateTest scenarios (150+ components)

• Reduce static & dynamic footprint

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

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

• Reduce no. of context objects created by (n – 1) / n

n = no. of components deployed in a single process

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

Assembly Optimizer

Factory

CHCH

CH

CH

CH

CH CHCH

Evaluating Physical Assemblies

• Boeing’s BoldStroke Basic Single Processor Scenario• Consists of 4 components

• Timer – Periodically sends refresh signal to the GPS• GPS – Calculates new co-ordinates of the aircraft in response

to Timer signal• Airframe – Processes new location inputs from GPS• Display – Updates the new location of the aircraft in the

navigation display47

Applying Physical Assemblies to BasicSP Scenario

• Assumption: GPS, Airframe and Display components are deployed on a single processor board

• Applying physical assemblies • Combines GPS, Airframe and Display components into a

single physical assembly (BasicSPAsm)• Maintains the same number of connections• Timer component not combined (due to clash in port names)

48

Experimental Results: BasicSP Scenario• Testbed

• Linux 2.6.20 FC6

• Dual 2.4Mhz processor

• 1.5GB RAM

• Evaluation for larger applications (~150 components) is in progress

49Physical assembly mapping reduces the footprint significantly

Static footprint reduction of ~45%

Dynamic footprint reduction of ~10%

50

Application Specific Optimizations: Unresolved Challenges2.Lack of application context

• Optimization decisions relegated to run-time

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

• Settle for near-optimal solutions

• Missed middleware optimization opportunities

51

Application Specific Optimizations: Unresolved Challenges2.Lack of application context

• Optimization decisions relegated to run-time

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

• Settle for near-optimal solutions

• Missed middleware optimization opportunities

• e.g., allocation of RT-CORBA thread pools and lanes

• Large overhead compared to collocated calls

Cannot be solved efficiently at middleware level alone!

Invocation within the same pool/lane (12µs)

Invocation to a different pool/lane (150µs)

Solution Approach: Use Application Context from Models• Use application structure &

context available in models• Create fast path within

middleware for physical assemblies

• Cross-pool/lane proxy• Create platform mappings to use

fast path• E.g., Use matching real-time

policies as additional constraint when creating physical assemblies

• Configure middleware resources efficiently

• E.g., place physical assemblies with matching policies in the same thread pool or thread pool with lanes

52

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

CH CH

CHCH

Assembly Optimizer

Factory

CHCH

CH

CH

CH

CH CHCH

53

Context-driven Optimization Evaluation Criteria • Improve performance

• t = no. of cross-pool/lane interactions between components within an assembly

• Transform t remote calls to t cross-pool/lane 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

Experimental Results: Cross pool/lane proxy

54

Standard deviation <= 3µs

Max latency improved by ~50%

99% latency improved by 60-66%

Average latency improved by 60 – 66%

Significant performance benefits with cross pool/lane proxy!

55





56

Summary of Research ContributionsTopic Benefits

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

Address composition scalability concerns by employing model-weaving 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


Novel approach to system integration based on model composition

Supports functional integration of heterogeneous middleware

Generation of integration glue-code directly from models

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.

A novel mechanism for mapping an assembly as a component to both reduce application footprint and increase performance

57

Summary of PublicationsCategory Publications


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


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. Component-based System Integration via (Meta)Model Composition, 14th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS), Tucson, AZ, March 2007

2. System Integration via Model Composition, Designing Software-Intensive Systems: Methods and Principles, Edited by Dr. Pierre F. Tiako, Langston University, OK. (Submitted)

First Author Second Author

58

Concluding Remarks

• Component middleware is an emerging paradigm

• 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

• Performs optimizations on component middleware that were previously infeasible

• Exploit application context made available by MDE tool-chain

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

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

Questions?

59

60


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



61

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

62

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

63

Traditional DOC Middleware Limitations• Unable to provide multiple, alternate

views per client

Component

Client C

Client A

64


views per client

• Unable to navigate between interfaces in a standardized fashion

Component

Client C

Client A

65

Traditional DOC Middleware Limitations• Unable to provide multiple,

alternate views per client


• 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);

66


views per client


• 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


List of FilesQoS Specs ComponentInterconnections

ImplementationDLL DLL

QoSProperties

Checksum


ImplementationDLL DLL

67


views per client


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

Java Component C++ Component C# Component

68

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

69

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

70

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



71

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

72

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

73

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

74

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

75


Manager

ScaleQosket

CropQosket

Compress Qosket



Predictor



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/)

76


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

Systems• Research Area 2: Expression of Design Intent• Research Area 3: Component System



77

• 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

78

• 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

79


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.

80

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

81

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




Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket




Stream 4

Stream 3

Stream 2

Stream 1

System Composition: Unresolved Challenges

82




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

83




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’

84

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

85





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

86





• 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

87

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’

88

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

89

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

90

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

91

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

92

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

93

Research Contributions

Category Benefits Publications


• 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)

94


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

Systems• Research Area 2: Expression of Design Intent• Research Area 3: Component System



95

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

96


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

97

<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?

98

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!

99

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

ImplementationImplementation

Component Assembly Configuration

Component Assembly Manifest

Application Assembly Configuration

100

PICML (CCM)

PICML (.NET)

CCM Models

.NET Web Service Models

PICML (CCM+.NET)

GME Composition


.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

101

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

102

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

103

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

104

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

105

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

106

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

107

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

ImplementationImplementation

Component Assembly Configuration

Component Assembly Manifest

Application Assembly Configuration

Support development of heterogeneous systems

108

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

109

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

110

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

111

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)

112

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

Model-Driven Engineering of Component Middleware-based Systems Vanderbilt University Nashville,...

Documents

Transcript of Model-Driven Engineering of Component Middleware-based Systems Vanderbilt University Nashville,...