1

Component Assembly Evaluation

• Simple C++ expressions

• Operators ( +, *, f() )

• Operands ( x, y, a )

• A compiler will optimize the evaluation of the expression

• Well-known optimizations

• Component assembly

• No optimizations performed!

• Can we do better?

• Exploit the metadata available at the asssembly level

• Optimize evaluation of expression

void foo () {

int x = 1;

double y = x + 7;

float a = x * y;

short c = f(a, y);

}

short f (float x1, double y)

{ return x1 * x1 + y * y; }

2

Middleware

MiddlewareServices

DRE Applications

Operating System& Protocols

Hardware & Networks

DRE Systems: The Challenges Ahead

•DRE systems

•extremely sensitive to Limit to how much application functionality can be refactored into reusable COTS middleware

•Middleware itself has become very hard to use & provision statically & dynamically

IntServ + Diffserv

RTOS + RT Java

RT/DP CORBA + DRTSJ

Load BalancerFT CORBA

Network latency & bandwidth

Workload & Replicas

CPU & memory

Connections & priority bands

RT-CORBA

RT-CORBAServices

RT-CORBAApps

J2ME

J2MEServices

J2MEApps

DRTSJ

DRTSJServices

DRTSJApps

•Component-based DRE systems are also very hard to deploy & configure

•There are many middleware platform technologies to choose from

Gigabit Ethernet

Gigabit Ethernet

3

Where is “Platform-Independence”?• Coming soon to an installer near you • Refactor existing metamodel to PICML

(the new one)

• Platform-Independence™

• Write GReAT transformations

• Smooth upgrades

• New capabilities

• Generate .NET artifacts

• Component Interfaces

• Assemblies

• Assembly manifests

• Target .NET CLR

Platform Independent Component Modeling

Language(PICML)

PICML for CCM

PICML for .NET

OMG D+C Descriptors

.NET assembly

descriptors

GReAT Transformations

Interpreters Interpreters

CCM Runtime

.NET CLR

4

What about scalability?

• Scalable modeling requirements• Eliminate redundancy• Fast UI response time• “Less is more”

• Scalable Features in PICML• Hierarchical assemblies

• If you add a feature, people will use it; often in an unexpected fashion

• Attribute mapping• Initialize attributes at

assembly level• Coming soon

• Property mapping• Similar to attribute mapping

• Pre-defined blocks

5

Enforcing Policies on Components

• Allow transparent injection of policies

(add-hook ‘invoke-hook ‘policy)

• Models as vehicles

• Capture policies as metadata

• Single meta-programmable injection framework

• Instantiated by CIDL compiler

• Orthogonal evolution of framework & policy

Executors

Servants

Executor Stubs

Skel

IDL

Stub

CIDL

Executor IDL

MetaProgrammable Injection Framework

QoS Contract Injection

Your Policing code

Fault Injection

PICML

Generated

Hand-Written

Generates

Inherits

Delegates

Injects

6

Component-based UAV system Challenges (5/5)• Automating propagation of

changes• Typical in DRE systems

evolution• Currently changes propagated

in an ad-hoc fashion

• Redundant effort• Cascading effect

• Change to a single UAV stream

• Needs to get propagated to all instances of the stream

– 1 stream per UAV – n streams in total

(n>=50)• Difficult to estimate effect of

changes

Control Center Display

SystemResourceManager

LocalResourceManager

Sender ReceiverCrop

Qosket

Compress Qosket

Scale Qosket

Compression QoS Predictor

Scaling QoS Predictor

Cropping QoS Predictor

Stream 4

Stream 3

Stream 2

Stream 1

7

Middleware

MiddlewareServices

DRE Applications

Operating System& Protocols

Hardware & Networks

RT-CORBA

RT-CORBAServices

RT-CORBAApps

J2ME

J2MEServices

J2MEApps

DRTSJ

DRTSJServices

DRTSJApps

Promising Solution: Model Driven Development (MDD)

• Develop, validate, & standardize generative software technologies that:

1. Model

2. Analyze

3. Synthesize &

4. Provision

multiple layers of middleware & application components that require simultaneous control of multiple QoS properties end-to-end

• Partial specialization is essential for inter-/intra-layer optimization & advanced product-line architectures

Goal is to enhance developer productivity & software quality by providing higher-level languages & tools for middleware/application developers & users

<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>

<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>

Gigabit Ethernet

Gigabit Ethernet

8

Concluding Remarks• Models can be used as vehicles

• To automate non-scalable activities• To identify & eliminate redundancy• To identify & perform optimizations not possible otherwise• To specify policy

• Middleware & associated frameworks (in conjunction with models)• To execute on instructions from models• To enforce policy

9

Challenge 2: Lack of Tools for Component Composition

• Once designed, components are implemented, built and packaged into a single run-time artifact

• Add/remove functionality iteratively• Each component participates in a variety of contexts & roles• Code for each context & role

• Always present, or• Dynamically loaded using strategies

• Add up to the time/space overhead of components• Lack of tools & abstractions

• To build, store, retrieve, version components• Previous generation middleware abstractions insufficient

• Maintain multiple lean & mean implementations of application components

10

Challenge 3: Lack of Tools for System Composition

• Components are developed in isolation• Without application context• Combined into assemblies to realize functionality

• Limited composition granularity• Restricted to interactions via ports, e.g., elements on a

motherboard• Separate implementations• Source of time/space overhead

• Lack of tools for fine-grained composition• Single implementation with all functionality, e.g. System-On-a-

Chip (SOC)

11

Challenge 4: Lack of Optimization Automation Infrastructure

• Variety of optimizations spanning different stages in lifecycle• Application context-driven (Design-time)• Platform-driven (Operating System, language) (Development

time) • Composition-driven (intra-technology, i.e., middleware)

(Development/Integration-time)• Integration-driven (inter-technology, i.e., all of the above)

(Integration-time)• Existing tools

• Can do one or two of the above• Never all of the above

• Perform optimizations on different artifacts• Lack common underlying representation

• Operate at low-level• Lack high-level abstraction

12

Challenge 3 Resolved: Exploit semantics of component models

• Define a meta-language for application composition• Operators (port operations)• Operands (component ports, components, component assemblies)

• An Application is an equation (or sentence) in this language• Optimize inefficient sentences into efficient ones

• Define execution equivalence semantics between sentences• Theoretically, e.g. using I/OAutomata (needs further investigation) • Empirically, e.g. Validate using CUTS • Build catalog of equivalent sentences

• Sentence A is equivalent to sentence B, iff the effect of evaluating A will yield similar externally observable results as evaluating B, in either the same context C, or a context C’ reducible to C

• E.g., Invoking a method over IIOP vs UIOP• Fuse individual component implementations of an assembly

• Opportunistically & auto-magically when semantics allow such fusion• Component Assembly Fusion == System-On-a-Chip

13

Challenge 4 Resolved: Use Models as Integration Carriers

• Use models as carriers (vehicles) to carry optimization information• Similar to request processing in network stacks with zerocopy

semantics• Request invocation/upcall is done via a single thread context

propagated between layers in the networking stack• Different optimizations (layer processing) associated on the

same model (context) • Spans entire life-cycle of component development

• Design time, Development time, Integration time• Share common underlying representation across different

stages of life-cycle• Exchange integration information with other tools

14

Integration of Heterogeneous Systems• Complex Systems are rarely

implemented using a single component middleware platform

• Every system needs some kind of integration

• Integration with legacy systems

• Integration with COTS systems

• Integration with client systems

• Support for integration with systems is critical to success of component middleware

• Also is backward compatibility

15

Related ResearchCategory Related Research

16

Challenge 4: Ineffective Tool Support for System Integration

Unresolved Challenges

• Integration of heterogeneous systems are almost always done at middleware level or lower

• Potential for major disruption at integration time

• Renders enhanced tool support for other stages of system development meaningless

• Integration purely at the middleware level is error-prone

• Need for higher levels of abstraction for integration of systems

CORBA Component

Model (CCM)

Microsoft .NET Web Services

Enterprise Java Beans (EJB)

17

• Presence of models of platforms to be integrated offers a possible solution

• Significant requirements from modeling infrastructure

• Support composition of metamodels

• Support independent evolution of

• Composition

• Things being composed

• Allow load/save of models corresponding to both platforms in the composed metamodel

CORBA Component

Model (CCM)

Microsoft .NET Web Services

Enterprise Java Beans (EJB)

Challenge 4: Ineffective Tool Support for System Integration

18

Proposed Approach: Multi-Platform System Integrator Tool• Enhance modeling infrastructure to

support seamless composition of metamodels

• Work with GME infrastructure team!

• Utilize enhanced infrastructure support to

• Refactor PICML• Allow integration of systems

using both .NET & CCM• Develop a pluggable glue-code

framework for • Bridging/Adapting cross-

platform invocations• Generate code to perform

adaptation utilizing above framework

PICML (CCM)

PICML (.NET)

CCM Models

.NET Web Service Models

PICML (CCM+.NET)

GME Composition

CCM Deployment descriptors

.NET Deployment descriptors

CCM Deployment descriptors

.NET Deployment descriptors

CCM+.NET Web Service

Models

19

Proposed Approach: Criteria for Evaluation

• Demonstrate feasibility of integration by prototyping an application

• Bridges/adapts calls from CCM to .NET Web Services & vice-versa

• Demonstrate feasibility of automation of integration done at modeling level

• Identify & document requirements from modeling infrastructure (if any) for future improvements

PICML (CCM)

PICML (.NET)

CCM Models

.NET Web Service Models

PICML (CCM+.NET)

GME Composition

CCM Deployment descriptors

.NET Deployment descriptors

CCM Deployment descriptors

.NET Deployment descriptors

CCM+.NET Web Service

Models