1

Assessing Contemporary Modularization Techniques for

Middleware Specialization

Akshay Dabholkar & Aniruddha Gokhaleaky@dre.vanderbilt.edu

OOPSLA ACoM 2008 Workshop

Oct 19, 2008

1

2

Motivation: Intelligent Transportation Systems

Gives rise to disparate middleware specialization needs i.e., minimizing footprint, maximizing throughput, real-time computation, dynamic adaptation to unpredictable runtime changes

Dynamic and constantly evolving systems

Rich in communication and information exchange

Stringent QoS and performance requirements

Invariably require middleware solutions and optimizations

Intelligent Transportation Systems: An example DRE system

Resource Constrained

Real time (customization)

High Performance

Differentiated Services

Real time

High Performance

Differentiated Services

Adaptive to weather

2

3

Challenges in Middleware Specialization

Dynamic middleware-based systems require context specific optimizations and adaptations i.e., middleware specialization

How can we identify these specializations?

Goal is to enable specializations at all stages of development life cycle in an integrated manner.

Layered Middleware

When? What?

3

COMPUTATIONAL REFLECTION

How?

4

Specialization Type

DEVELOPMENT TIME

COMPILE TIME

RUN TIMEDELOYMENT / STARTUP TIME

C ustomizable

Pre-Postulated (S tatic)

Lifetime-Dependent Middleware S pecialization

T unableC onfigurable

J ust-In-T ime (Dynamic)

Mutable

Application Lifetime

INIT TIME

Challenge 1: When to specialize?

Pre-postulated Customizableo compile/link time, after

development timeo Generates specialized versionso e.g. static aspect weaving, compiler

flags, precompiler directives, Configurableo deployment/startup time, after

compile timeo e.g. CORBA PI, command-line

parameters, ORB configuration files

4

Just-in-time (JIT) Tunableo Fixed middleware coreo After the startup time but before run time – init / bootstrap timeo e.g. Component Configurator & Virtual Component patterns, two-step process (compile

time: AOP, run time: Reflection)

Mutableo Most powerful (adaptive)o No concept of fixed middleware core so can

evolve into something completely different or unexpected

o e.g. MetaSockets, Reflection, Late Composition, dynamic aspect weaving

5

Feature Pruning Traditional middleware provides a broad

range of features (generic) for multiple application domains

Remove unessential features Benefits: reduces footprint, improves

performance

Challenge 2: What to specialize?

Feature Augmentation Traditional middleware may not provide

the desired supporting features Add the required features Commonly used by next generation

middleware designed to overcome the limitations of monolithic architectures

Particularly useful to incorporate domain-specific semantics within middleware

Context: Resource constrained embedded software require footprint management

Solution: Map application features to the supporting middleware features and optimize the middleware

Control System

Self Test

ActuatorSensor

Self Test

Assembly

Position Actuator

Position Sensor

Speed Sensor

Internal Memory Size

+ +

Mandatory Feature

Optional Feature

Inclusive OR

+ Feature Cardinality

Need for consistent and correct feature management

5

6

Challenge 3: How to specialize?

Computational Reflection

Ability to introspect, reason about and adapt own behavior without exposing implementation

6

Model-Driven Engineering

PICML

Component Developer

IDL FilesDefine interfaces

1

Model interfaces

Import/Export IDL2

OCML

Domain Expert

Define options and valid configurations

3

Application Model/

Model Application

Application Developer

5CUTS

6

Select Components

Q/A Specialist

Define experiments

7

Generate experiments8

Refine application QoS based on experiments

Benchmark Application9

Associate rules with meta-model elements

4

Integrates MDSD with QoS-enabled component middleware

ClassMethod1 Method1

Pre Code

Post Code

Aspect

AOP for Middleware Specialization Factorization and separation of cross-cutting

concerns from the middleware core Generate customized versions of

middleware for application-specific domains e.g. CORBA Interceptors, Two-step process

(compile time: AOP, run time: Reflection)

7

AUGMENTATION

PRUNING

COMPUTATIONAL REFLECTION

ASPECT ORIENTED PROGRAMMING (AOP)

MODEL-DRIVEN ENGINEERING (MDE)

TUNABLE

MUTABLE

CUSTOMIZABLE

CONFIGURABLE

PRE-POSTULATED JUST-IN-TIMELIFECYCLE STAGES

PA

RA

DIG

M-D

EP

EN

DE

NT

FEATURE-

MANIPULATION

Taxonomy of Middleware Specialization Techniques

Overlapping dimensions share concepts e.g. MDE/AOP includes both feature pruning & augmentation and can be used for customization as well as tuning

Dimensions can be combined to produce new variants of specialization

Serves as a guideline for synthesis of tools for design, V&V, analysis of specializationsThree dimensional Taxonomy

of Middleware Specializations

How?

What?

When?

7

8 8

Assessment of the Taxonomy

COMBINATIONS USE CASES STRENGTHS WEAKNESSES RELATED WORK

Pre-postulated + AOP

Weave/Prune at compi le-time Transparency without affecting core

Code Bloating FACET, CLA, FOCUS, Bypass ing Layers , AspectOpenORB

Pre-postulated + MDE

Weave/Prune only known features

Elegant des ign Runtime specia l i zations not poss ible

DTO, CLA, Modelware

Pre-postulated + Refl ection

Inspect target platform features

Useful during deployment Diffi cult to predict runtime conditions , preconceive hooks

AspectOpenORB, DTO

Just-in-time + AOP

Dynamic weaving of features Dynamic Adaptation Requires native platform support

JAsCo, PROSE, Abacus

Just-in-time + MDE

Sel f-heal ing/correcting systems

Val idation of Specia l i zations

Incur runtime overhead Models@Runtime

Just-in-time + Refl ection

Introspect runtime appl ication features

Dynamic Adaptation & reconfi guration

Can cause unpredictable behavior, preconceive hooks

AspectOpenORB

AOP + FOP ISD and SPLs Better modularization of crosscutti ng features than AOP a lone

Runtime specia l i zations not poss ible, cause confl icts

AFMs, Caesar

FOP + MDE SPLs Better compos ition of features

Runtime specia l i zations not poss ible, cause confl icts

FOMDD

AOP + Refl ection Composition based on appl ication requirements

On-demand feature weaving

May cause confl icts AspectOpenORB

AOP + MDE + FOP + Refl ection

Des ign/Weave/Prune va l id features combinations

Systematic, correct specia l i zation process

Safe specia l i zations i s chal lenging

Research Needed

9

Open Middleware Specialization Research Areas Based on the survey at least four research areas show up:

Specialization of Domain-specific middleware services

Mutable middleware specialization is powerful but a dangerous technique

Application inconsistency caused by overlapping specialization techniques (similar to feature interaction problem in pattern recognition)

No single specialization that can adapt a entire distributed application

→ Safe specializations?

→ V&V of specializations?

→ Integrated specializations?

→ Pattern Languages of Specializations?

An Integrated Tool Suite based on specialization pattern languages to support synthesis, verification and validation of specializations9

10

Thank You!

Questions?

10