Arvind S. Krishna [email protected] Institute for Software Integrated Systems

OPTEML: OPTEML: OpOptimization timization TTechniques echniques for for EEnhancing nhancing MMiddleware Quality of iddleware Quality of

Service for Service for Product-Product-lline Architecturesine Architectures

Arvind S. [email protected]

Institute for Software Integrated Systems

Vanderbilt University Nashville, Tennessee

http://www.dre.vanderbilt.edu/~arvindk/proposal.pdf http://www.dre.vanderbilt.edu/~arvindk/proposal.pdf

Motivation

AirFrame

GPS

FLIR

Legacy distributed real-time & embedded (DRE) systems have historically been:• Stovepiped• Proprietary • Brittle & non-adaptive• Expensive• Vulnerable

Consequence: Small HW/SW changes have big (negative) impact on DRE system QoS & maintenance

GPS

FLIRAP

Nav HUD

IFF

Cyclic Exec

F-15

AirFrame

APNav HUD

GPSIFF

FLIR

Cyclic Exec

A/V-8B

AirFrame

Cyclic Exec

AP

Nav HUD

IFF

F/A-18

AirFrame

AP

Nav HUDGPS

IFF

FLIR

Cyclic Exec UCAV

http://www.takeourword.com/images/persistence-of-memory.jpg

F-15productvariant

A/V 8-Bproductvariant

F/A 18productvariant UCAV

productvariant

Product-line architecture

Hardware (CPU, Memory, I/O)OS & Network Protocols

Host Infrastructure MiddlewareDistribution Middleware

Common Middleware Services

Motivation

•Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility •Essential for product-line architectures (PLAs)

AirFrame

APNav

HUD GPS

IFF

FLIR

Domain-specific Services

F-15productvariant



productvariant




Common Middleware Services

Motivation


•However, standards-based, general-purpose, layered middleware is not yet adequate for the most demanding & mission-critical PLA based DRE systems

AirFrame

APNav

HUD GPS

IFF

FLIR

Domain-specific Services

F-15productvariant



productvariant



Customized Middleware

Motivation


•However, standards-based, general-purpose, layers middleware is not yet adequate for the most demanding & mission-critical PLA based DRE systems

AirFrame

APNav

HUD GPS

IFF

FLIR

My research optimizes middleware for PLA-based DRE systems

Presentation Road Map Technology Context Research Challenges Related Research Research Progress Proposed Research Middleware

Specialization Techniques Dissertation Timeline Concluding Remarks

Overview of Product-line Architectures (PLAs)PLA Characteristics: Scope Commonalities & Variabilities (SCV)•SCV analysis is a process that can be applied to identify commonalities & variabilities in a domain to guide development of a PLA [Coplien]

James Coplien et al. Commonality & Variability in Software Engineering, IEEE Software 1998

Applying SCV to Bold Stroke–Scope: Bold Stroke component architecture, object-oriented framework, & associated components, e.g., GPS, Airframe, & Display

OS & Network ProtocolsHost Infrastructure Middleware

Distribution Middleware

Common Middleware ServicesDomain-specific Services

AirFrame

APNav

HUD GPS

IFF

FLIR

Reusable Architecture Framework

Reusable Application

Components

Overview of PLAsApplying SCV to Bold Stroke–Commonalities describe the attributes that are common across all members of the family• Common object-oriented framework & set of components

–e.g., GPS, Airframe, Navigation Display components • Common middleware infrastructure

–e.g., Real-time CORBA & a variant of Lightweight CORBA Component Model (CCM) called Prism

GPSComponent

DisplayComponent

AirframeComponent

Heads UpDisplay

Bold Stroke Common Components




Overview of PLAs

GPSComponent

DisplayComponent

AirframeComponent

Heads UpDisplay

GPS = 20 HzGPS = 40 Hz GPS=20Hz

Bold Stroke Common Components

Air AirFrame

AP

Nav HUD

GPS IFF

FLIRAP

Nav HUD

GPS IFF

FLIR

AirFrame

AP

Nav

HUD

GPS

IFF

FLIR

F/A 18 F F 15K UCAV

Frame APNavHUD

GPSIFF

FLIR

Applying SCV to Bold Stroke–Variabilities describe the attributes unique to the different members of the family

• Product-dependent component implementations (GPS/INS)

• Product-dependent component connections

• Product-dependent components (Different weapons systems for security concerns)

• Different hardware, OS, & network/bus configurations




Mature PLA Development Process

Component Repository

Com

p

Com

p

Com

p

Com

p

Com

p

Com

pC

omp

Com

p

Com

p

Com

pC

omp

Com

p

Com

p Com

p

Com

p

Com

pC

omp

Com

p

Com

p

Deployment Platforms

•PLAs define a framework of components that adhere to a common architectural style

•Model driven development (MDD) & domain-specific modeling languages (DSMLs) are used to:– Glue components together

– Synthesize artifacts for deployment onto platforms, e.g., J2EE, .NET, & CORBA

Middleware Layers for PLAsMiddleware Evolution• Middleware supports application requirements in different domains• Often exhibits a standards-based, general-purpose, & layered architecture •Host infrastructure middleware encapsulates native OS mechanisms to create reusable network programming components

•Example: ACE toolkit & JVMs

www.dre.vanderbilt.edu/ACE

Examples of QoS variabilities• OS priorities, which differ on Sun,

VxWorks, Windows, Linux/RT-Linux

• Diverse locks & IPC mechanisms

•Distribution middleware defines higher-level distributed programming models whose reusable APIs & components automate & extend native OS capabilities

•Avoids hard-coding dependencies on OS, languages, & location

•Examples: Real-time CORBA, COM+, Distributed Real-time Java, Java RMI,

www.dre.vanderbilt.edu/TAO

Examples of QoS variabilities•Round-trip timeouts, protocol properties, (de)marshaling strategies, concurrency models

•# of threads, stack sizes

Middleware Layers for PLAs

•Component middleware is a class of middleware that enables reusable services to be composed, configured, & installed to create applications rapidly & robustly• Components encapsulate application

“business” logic• Containers provide execution

environment for components• Interact with underlying middleware to

leverage middleware services, such as events, fault-tolerance etc

Examples of QoS variabilities• Type of containers (e.g., real-

time, transient, persistent)• Services QoS properties (e.g.,

event channel vs. direct dispatch)

Instrument Cluster

Positioning Unit

GUIDisplayRefresh

GPSLocation

LEDDisplayRefresh

GetLocation

RateGenPulse

Rate

GPS

MyLocation

Refresh Ready

www.dre.vanderbilt.edu/CIAO

Middleware Layers for PLAs

Presentation Road Map Technology Context Research Challenges Related Research Research Progress Proposed Work Middleware


Overview of Research ChallengesResolving the tension between•Generality Middleware is designed to be independent of particular application requirements

Customized Middleware Stack Standards-based, General-purpose, Layered Middleware Architecture

Product-line Variant

•Specificity PLAs are driven by the functional & QoS requirements for each product variant

Research Challenges

Container

ClientOBJREF

in argsoperation()out args +

return

IDLSTUBS

ORBINTERFACE

IDLSKEL

Object Adapter

ORB CORE GIOP/IIOP/ESIOPS

Component(Servant)

Services

ProtocolInterface

ComponentInterface

ServicesInterface

DIIDSI

Research Challenges Addressed in OPTEML

SSL STDPOA

Asynchrony

Middleware fine-grain componentization challenges

Configuration evaluation & validation challenges

Specialization challenges

Taxonomy of Research ContinuumB

indi

ng T

ime

ApplicabilityGeneral Specific

Run

-tim

eD

esig

n-tim

e

Optimization dimensions• Applicability General-purpose to more application-specific

• A general-purpose optimization can be applied across all PLA variants, while application-specific targets a particular variant

• Binding time Run-time to design-time• Determines when the optimizations are bound, i.e., run-time

system execution, design-time system development

Prior research has focused on a continuum of optimizations

General-purpose Optimizations B

indi

ng T

ime


Run

-tim

eD

esig

n-Ti

me

General-purpose optimizations are broadly applicable algorithmic & data-structural optimizations within the middleware/OS/protocols to improve QoS

• Applicability Can be used for a range of applications across different domains

• Binding time Design-time & run-time

Related ResearchResearch Category

Related Research

Request Processing Optimizations

• Pyarali et al., “Applying Optimization Patterns to the design of Real-time ORBs”, 5th COOTS Conference, 1999

• Wang et al. “Collocation Optimizations,” IEEE Distributed Systems, 2001

Demultiplexing & Threading optimizations

• Feldmeier, “Multiplexing Issues in Communications System Design”, ACM SIGCOMM, 1996

• Hutchinson et al. “The Design of the x-kernel”, ACM SIGCOMM, 1998

Patterns for Connection Management

• Schmidt, “Acceptor & Connector: Design Patterns for Actively & Passively Initializing Network Services”, Euro PLOP Conference, 1997

Patterns for Request Processing

• Pyarali et al., “Asynchronous Completion Token: An Object Behavioral Pattern of Efficient Request Processing, PLoP Conference, 1999

Protocol Processing Related Optimizations

• O’Ryan et al., “Design of a Pluggable Protocol Framework”, Middleware 2000

• O’Malley et al. “USC: A Universal Stub Generator”, SIGCOMM 94

Schmidt et al., “Pattern Oriented Software Architecture 2”, Addison Wesley

http://www.dre.vanderbilt.edu/~arvindk/proposal.pdf

General-purpose Optimizations: What is Missing?

Need to determine right

hooks

Unresolved challenges– Different product-lines achieve

different benefits/liabilities from enabling/disabling different optimizations

• e.g. type of ORB reactor, type of queue, type of connection management strategy etc.

Solution: Configuration-driven Optimizations

– How to systematically determine what optimizations are ideal for a particular deployment & product variant

Configuration-driven Optimizations


Bin

ding

Tim

eR

un-ti

me

Des

ign-

time Hook for the

concurrency strategy

Hook for marshaling strategy

Hook for the connection management strategy

Hook for the underlying transport strategy

Hook for the event demuxing strategy

Configuration-driven optimizations tune compiler/middleware/web-server configuration knobs to maximize application QoS for a particular use case

•Applicability Technique is broadly applicable, but a particular configuration may be specific to a particular application use case

•Binding time Typically bound at system initialization-time

Related Research Research Category

Related Research

Functional Correctness of Software Configurations

• Memon et al. “Distributed Continuous Quality Assurance”, ICSE 2004, Edinburgh, Scotland

• Yilmaz et al. “Covering Arrays for Efficient Fault Characterization in Complex Configuration Spaces”, ISSTA, 2004

Continuous Monitoring

• Childers et al. “Continuous Compilation: A New Approach to Aggressive & Adaptive Code Transform”, IPDPS 2003, Next-generation software workshop

Generative Programming Techniques

• Rutherford et al. “A Case for Test-Code Generation in Model-driven Systems”, GPCE 2003, Erfurt Germany

Compiler Technology

• Yotov et al. “A Comparison of Empirical & Model Driven Optimizations”, PLDI 2003

Web-service Configuration importance estimation

• Sophiktomol et al. “A Method for Evaluating the Impact of Software Configuration Parameter on E-Commerce Sites”, Workshop on Software & Performance, 2005

Configuration-driven Optimization: What is Missing?

http://www.atl.external.lmco.com/projects/QoS/

• Krishna et al. “CCMPerf: A benchmarking tool for CORBA Component Model Implementations”, RTAS 2004, Toronto Canada

• Krishna et al. “Empirical Evaluation of CORBA Component Model Implementations”, Springer-Verlag Journal on Real-time Systems, March 2005

Unresolved challenges–These optimizations cannot

eliminate middleware generality

–Overhead from specification compliance, redundant checks, & indirection

•e.g., benchmarking efforts revealed that even with most optimal configuration, indirection overheads are costly

–How to optimize the request processing path to improve performance

Solution: Partial Specialization Optimizations

Partial Specialization Optimizations


Bin

ding

Tim

eR

un-ti

me

Des

ign-

time

Partial Specialization optimizations customize programming-languages/middleware according to system invariants known ahead-of-time

Applicability Optimizations are highly context-specific Binding time Optimizations are generally applied at design-time

Related ResearchCategory Related Research

Automatic language mechanisms

• T. Mogensen & A. Bondorf, “Logimix: A Self-Applicable Partial Evaluator for Prolog”, Program Evaluation & Program Specialization conference (PEPM), 1993

• S.M. Abramov, “A Compiler Based on Partial Evaluation”, Problems of Applied Mathematics & Software Systems, Moscow State University Press,

Manual language mechanisms

• Kiczales, “An Overview of AspectJ”, Lecture Notes in Computer Science, 1999• Lohmann et al. “Generative Programming with Aspect C++”, GPCE 2004, Vancouver, Canada

• Todd Veldhuizen “Using C++ meta programs”, C++ Report 1999

Specification level mechanisms

• Ira Baxter “Design Maintenance System”, Semantic Designs Inc,• Goodman “Processor for Multiple Language Application”, Promula

Domain: Operating Systems

• Massalin et al. “The Synthesis Kernel”, Computing Systems Journal, 1998• Pu et al. “Optimistic Incremental Specialization: Streamlining a Commercial Operating System”, SOSP 95

Domain: Feature oriented specialization

• Zhang et al. “Towards Just in Time Middleware”, Aspect Oriented Software Engineering, (AOSD 2005), Chicago, 2004

• Zhang et al. “Resolving Feature Convolution in Middleware”, ACM SIGPLAN OOPSLA Conference, Vancouver, Canada 2004

Partial Specialization: What is Missing?Lack of Tool Support

–Automatic specialization generally restricted to declarative languages, such as lambda

–Little support for OO languages such as C++/Java

Lack of Middleware approaches–Middleware is designed for

generality, these techniques hold promise when applied to middleware

–No approaches address middleware-related issues

Lack of approaches that deal with optimizations–AspectJ (Resolving Feature Convolution, Zhang et al.) did not focus on improving

performance using optimizations–Aspects are a delivery mechanism, the woven code can be suboptimal! – Aspects also add run-time overhead (need to link to library) create portability issues

+

Provides no guarantees on woven code

Challenge #1: Fine-grain Componentization

SSL STDPOA

Asynchrony

Middleware fine-grain componentization challenges

Middleware Feature Componentization ProblemContextEach variant in a PLA may require only a subset of all the middleware features

Research Challenges•General-purpose optimizations address performance issues, but do not address feature-driven componentization

•Monolithic ORB architectures put all code in one executable

•Conditional compilation allows fine-grained componentization but

• Increases number of configuration settings

• Hard to maintain & add new features

SSL STDPOA

Asynchrony

VME RTPOA

Synchronous

Addressing Middleware Customizability Challenges for PLAsSolution Approach Micro ORB Architectures• Identify ORB services whose behavior

may vary, e.g., • Object Adapters, Anys, Protocols,

(de)marshaling, & buffer allocation mechanisms

• Move these out of the ORB

Micro- ORBKernel

ObjectAdapters

TransportProtocols

IORParsers

Any

ObjectResolvers

MessageBuffer

Allocators

GIOPMessaging

CDRStreamReaders

Hypotheses: Our approach• Enables different levels of

customization • Is application transparent• Significantly reduces footprint• Allows easy addition of new

features without undue performance overheads

Addressing PLA Customizability ChallengesSolution Approach Micro ORB Architectures• Identify ORB services whose behavior may vary, e.g.,

• Object Adapters, Anys, Protocols, (de)marshaling & buffer allocation mechanisms

•Move these out of the ORB•Implement alternatives as pluggable strategies, i.e., virtual components [VC]

[VC] Corsaro et al. “Virtual Component Pattern,” Pattern Language of Programs”, Monticello, Illinois, 2003

MCASTPOA

STDPOA

MINPOA

Micro- ORBKernel

SSL ATM VME

RTPOA

ObjectAdapters

IIOP

TransportProtocols

IORParsers

Any

ObjectResolvers

MessageBuffer

Allocators

GIOPMessaging

CDRStreamReaders

Addressing PLA Customizability ChallengesSolution Approach Micro ORB Architectures• Identify ORB services whose behavior may vary:

• Object Adapters, Anys, Protocols, (de)marshaling & buffer allocation mechanisms

•Move these out of the ORB•Implement alternatives as pluggable strategies, i.e., virtual components [VC]

•Each product variant can then choose what component it does or does not require

•Application Transparent –No changes to CORBA interfaces–No changes to existing

implementations

Research ContributionsResearch Contributions– Levels of customizability coarse-

grain vs. fine-grain componentization• Fine-grain approach break component

into multiple sub-components– Policy driven approaches to fine-grain

componentization – Footprint Fine-grain approach has 50% reduction

compared with monolithic approach [DOA 02, 03] – Cost Adding new features for variants modularized (e.g., new protocol)– Performance enables all general purpose-optimizations [RTAS 03] &

real-time properties[ICDCS04] along critical pathMy Contributions Publications

Next Generation Middleware Design

Book Chapter: Middleware for Communications Wiley & Sons, New York, 2004

Real-time Performance & Predictability

International Conference on Distributed Systems (ICDCS) 2004Real-time Application Symposium (RTAS) 2003

Pluggable POA Architecture ORB Core Architecture

Distributed Objects & Applications (DOA) 2002Distributed Objects & Applications (DOA) 2003

Challenge #2: Configuration Evaluation & Validation

Configuration evaluation & validation challenges

Ad hoc Techniques for Configuration EvaluationContextEach variant in a PLA requires an appropriate set of middleware configurations to satisfy QoS properties

Impl

IDL Compiler

IDL

CIDL

CIDL Compiler

Executor IDL

IDL Compiler

Executors

Stub Skel

Servants

XMLComponentDescriptors

Handcrafted Generated Inherits Generates

build

BenchmarkBenchmark

However, the “means” (process for the mapping) are tedious, error prone & time-consuming for middleware

• e.g., for a simple 5 component scenario requires ~ 60 files each ~ 100-500 LOC

Problem–Configuration-driven optimizations

describe the “ends” (mapping requirements to parameters)

Ad hoc Techniques for Configuration Evaluation/Validation

Ad hoc Techniques for Configuration Evaluation/Validation

ACEDOC

TANGO

Ethernet

DisplayAirframe

GPS

ACEDOC

TANGO

Ethernet

GPSAirframe

Display

Problem–No systematic process to

evaluate & validate configuration settings across different platforms

–Configuration Evaluation• e.g., how do we ensure the

right middleware configuration for maximizing QoS for product-variants?

– Configuration Validation• e.g., how do we ensure that

configuration is semantically valid across different deployment scenarios?

Addressing Ad hoc Techniques for Evaluation & ValidationHypotheses: Our approach for different Product-variants• Eliminates accidental complexity in evaluating QoS of middleware

configurations• Enables validation of middleware configurations across diverse platforms• Can be applied to identify middleware configurations that most influence

end-to-end performance/latency/jitter (i.e., the “main effects”)

Solution Approach: Combine MDD Approach

– Raise the level of abstraction, i.e., think in terms of middleware configurations rather than lower-level source code

– Auto-generate information required to run & evaluate QoS of variants

with Quality Assurance Processes– Validate generated code across

different platforms

IDL Compiler

CIDL Compiler

Executor IDL

IDL Compiler

Executors

Stub Skel

Servants

XMLComponentDescriptors

delegate

s

Impl

Script

IDL

CIDL

ModelInterpreters

Build & Benchmark Generation DSML

BGML• Developed a domain specific modeling language (DSML) in GME to

evaluate middleware configurations to maximize application QoS

BGML Tool FeaturesChallenge 1 : How to capture different PLA communication

semantics?BGML Challenge Resolution• Provide modeling

constructs to depict one-way/two-way invocation semantics

• Modeling construct to depict events

• Interpreters generate platform specific code

• Eliminate accidental complexities in understanding IDL-C++ mapping

Two way synchronous

communication

One-way synchronous/asynchronous

(void) this->remote_ref_-> AcceptWorkOrderResponse (arg0, arg1);

BGML Tool FeaturesChallenge 2 : How to capture different PLA QoS characteristics

BGML Challenge Resolution• Provide modeling

constructs to capture latency/throughput and jitter QoS characteristics

• Automatic translation into code that samples data; calculates and computes these metrics

ACE_Sample_History history (5000);for (i = 0; i < 5000; i++) { ACE_hrtime_t start = ACE_OS::gethrtime (); (void) this->remote_ref_-> AcceptWorkOrderResponse (arg0, arg1); ACE_CHECK; ACE_hrtime_t now = ACE_OS::gethrtime (); history.sample (now - start); }}

Latency between ab

< x msecs

Throughput should be

more than y calls/sec

BGML Tool Features

Challenge 3 : How to capture PLA workloads, e.g., rate-based?

BGML Challenge Resolution• Tasks: Threads that

run at given/rate or continuous or are random (interactive load)

• TaskSet: Group tasks into sets having a given rate/priority

ACE_Barrier barrier (2);

// Generate the Background workload AcceptWorkOrderResponse_Workload<T> task0 (this->remote_ref_, arg0_, arg1_, barrier);AcceptWorkOrderResponse_Workload<T> task1 (this->remote_ref_, arg0_, arg1_, barrier);AcceptWorkOrderResponse_Workload<T> task2 (this->remote_ref_, arg0_, arg1_, barrier);

Operations at 20Hz/sec

Operations at 40 Hz/sec

CoSMIC Tool SuiteChallenge 5: How to model & generate middleware configurations

settings for PLA variants?

DocumentationPane

Option selection

BGML integrated with the Options Configuration Modeling Language (OCML)

CoSMIC Tool SuiteChallenge 6: How generate deployment information?

BGML integrated with Platform Independent Component Modeling Language

Virtual nodes

MappingThis MDD process automates ALL code required to enact a scenario• Deployment Plan – XML deployment information (PICML)• svc.conf – Configuration for each component implementation (OCML)• Benchmark code – source code for executing benchmarks (BGML)• IDL & CIDL files (PICML/BGML)• Build Files – MPC files (www.ociweb.com) (BGML)

MDD Quality Assurance ProcessEvaluating and Validating Middleware Configurations–Process output integrated with Skoll

(www.cs.umd.edu/projects/skoll)– Skoll QA processes validates

configurations across different platforms, compilers & OS

OCML

BGML

Skoll

BenchmarkInformation

IDL .cpp

Scriptfiles

ServiceConfig

files Internet

distributedsystem

TargetMachine

A

B

C

D

E

F

Model

ConfigurationInformation

A: Use MDD process explained earlier to capture PLA QoS concerns

B, C: Synthesize middleware configuration, benchmark and deployment information

D: Feed test code to Skoll frameworkE: Run on varied platforms to measure

QoS variationsF: Maintain database of results from

which patterns of configurations can be identified

Process time consuming.Do I need to run this process each time?

Main-effects Screening Process

Motivation– Identify the important configurations settings that

characterize complete configuration space

– Enhance Skoll to use a statistical techniques (Design of Experiments theory) to estimate & validate configuration importance

• e.g., G is most important parameter for the scenario followed by H

– Enables defining a region for required performance

– Penalty for leaving the region X msecs

Process Steps– Use MDD process to generate

artifacts

Research Contributions

Contributions Publications

Configuration “main effects” (MDD & Skoll)

Real-time Application Symposium (RTAS) 2005International Conference on Software Engineering (ICSE) 2005

BGML & CoSMIC Tool Suite

International Conference on Software Reuse (ICSR) Elsevier Science of Computer Programming, International Journal of Embedded Systems (Invited submission)

Distributed Testing & Quality Assurance

IEEE Software, Studia Infomatica Universalis Journal

Model-Driven QA processes for configuration evaluation & validation– Enhances Configuration-driven optimization techniques by providing a

reusable, automated process reproducible for different variants [RTAS05]– Addresses accidental complexities in code-generation [ICSR]– Addresses validation challenges across different hosts/configurations [IEEE

Software]– Documents configuration main-effects that can drive customizations or further

validation [ICSE 2005]

Challenge #3: Middleware Specialization

Specialization challenges

Where to Specialize?Where do we apply middleware specializations?– Research [Zhang et al.] showed that woven code is not always optimal– Identification of specialization points within the middleware is a key step

towards eliminating generality

Client OBJREF

Object(Servant)


return

IDLSTUBS

ORBINTERFACE

IDLSKEL

Object Adapter

ORB CORE GIOP/ IIOP/ESIOPS

2

3

5

4

1

1

2

3

4

5

Specialization on LocationRequest Header

CachingEliminate un-necessary

checks

Pre-create Request

Optimize for TargetLocation

Approach –Examined critical request &

response processing path

– Identified & documented places of generality

• Redundant checks & lookups along request processing path

– Implemented them as alternatives using a “hand-crafted” approach

Zhang et al. “Resolving Feature Convolution in Middleware”, OOPSLA Conference, Vancouver, 2004

Bold Stroke PLA ScenarioExample System• Basic Single Processor (BasicSP) –distributed real-time & embedded

(DRE) application scenario based on Boeing Bold Stroke• Timer Component – triggers periodic refresh rates • GPS Component – generates periodic position updates• Airframe Component – processes input from the GPS component &

feeds to Navigation display• Navigation Display – displays GPS position updates

ACE_wrappers/TAO/CIAO/DaNCE/examples/BasicSPCoSMIC/examples/BasicSP

Representative DRE application: “rate based” Events Control informationOperation simple data

Gleaning Scenario Invariants

Periodic Timer:Sends same

data repeatedly

Single method interfaces:

Sends same operation on

wire

A specific Reactor used

Protocol: A specific protocol used

Mapping Ahead of Time (AOT) System Properties to Specializations• Periodicity Pre-create marshaled

Request

• Single Interface Operations Specialize Request Path

• Reactor/Protocols Plug in right reactors (remove indirections)

Specialize Request Path

Specialize Middleware Paths•Create middleware fast paths based on different invariants

Normal layered path

Optimized Fast path processing

Request Processing Fast Paths •Normal layered path Uses general-purpose optimization for request lookup

•Optimized fast path Bypasses middleware layers to directly perform operation invocation

• Invariant: The same operation is invoked on a given connection

Pre-create Request

Specialize Request Creation•The trigger messages sent by the Timeouts do not have any data nor change across requests

Pre-create Request• Pre-create & marshal the request• Each time same request is sent to

the client• Update request ID of the request

only• Save cost of request construction

& marshaling

Request Header Creation• Creation of the header is costly!

Reactor SpecializationReactor Pattern•Reactor pattern separates the event detection from the demultiplexing

•Allows a single-thread to do both activities•Multiple Reactor implementations; need only one!

Reactor Specialization•Remove indirection, e.g., Reactor_Impl base class completely (all virtual methods concrete)

•No changes to component interface. Does not break compatibility

Similar Situations•Protocol framework only one protocol

•Locking Strategy enable/disable

Select Reactor

select ()

Reactor_Implselect ()

WFMO_Reactor

select ()

Thread_Pool Reactor

select ()

Specialization Catalog

Client OBJREF

Object(Servant)


return

IDLSTUBS

ORBINTERFACE

IDLSKEL

Object Adapter

ORB CORE GIOP/ IIOP/ESIOPS

2

3

5

4

1

1

2

3

4

5



checks

Pre-create Request


Client Side Specialization• Request Header Caching• Pre-creating Requests• Marshaling checks• Target Location

Server Side Specialization• Specialize Request

Processing• Avoid Demarshaling

checks

ORB Component Specialization• Multiple types of Reactor• Pluggable protocol

framework

• Specializations implemented using “hand-crafted” techniques:• What is needed? (1) enable new specializations to be added (2) delivery

mechanisms for automating this process

FOCUS Approach: Summary

SplRules

Foo (){ ….. ……. //hook …}

Middleware Developer

Application Devloper

Foo (){ ….. ……. …….. …}

Ruleselection

Evol

utio

n of

spec

ializ

atio

ns

Processing Phase–Middleware developer

• Annotates code with specialization points• Creates specialization rules (e.g., in a

database)• Creates GUI to infer specialization via high-

level questions: “do you need concurrency?”

Specialization Phase–PLA Application developer

• Uses GUI to choose type of specialization required

• Selection of right specialization rules• FOCUS tool: “Feature-Oriented

Customization” removes the generality by specializing hooks

Evolution–Add new specializations & maintain their dependencies

FOCUS: Specialization RulesSpecialization Rules

– Steps that are needed for systematically executing the specializations– Transformations (replace) similar to aspects (before/after join-points);

add dissimilar as no join-point to add an advice!

Client OBJREF

Object(Servant)


return

IDLSTUBS

ORBINTERFACE

IDLSKEL

Object Adapter

ORB CORE GIOP/ IIOP/ ESIOPS

2

3

5

4

1

1

2

3

4

5



checks

Pre-create Request


IIOP_Connection_Handler:in process_request ():add: TAO_ServerRequest &request = incoming.get_request ();replace: next_layer->process_request (); final_layer->process_request (request);

Work Completed•Capturing specialization rules

FOCUS: Specialization Rules

Foo (){ ….. ……. //hook …}

Rules

IIOP_Connection_Handler:in process_request ():add: TAO_ServerRequest &request = incoming.get_request ();replace: next_layer->process_request (); final_layer->process_request (request);

Rules

Rules

Middleware developers:

Annotate source with hooks

Middleware developers:

Specify transformations as rules; multiple rules

in a database

Work in Progress• Developing an XML schema for

capturing rules & dependencies• Aspects:

• run-time overhead; portability issues; add advice & tool-maturity

Container

ClientOBJREF


return

IDLSTUBS

ORBINTERFACE

IDLSKEL

Object Adapter

ORB CORE GIOP/IIOP/ESIOPS

Component(Servant)

Services

ProtocolInterface

ComponentInterface

ServicesInterface

DIIDSI

FOCUS: Transformations

Application DevloperRules

RulesRule Selection

Contai ner

Cl i entOBJREF

i n argsoperat i on()out args +

return

ORBINTERFACE Obj ect Adapter

ORB CORE VME

Component(Servant)

Services

ProtocolInterface

ComponentInterface

ServicesInterface

Customization points

Specialized Path

Customization Engine:

Transforms annotations

Work in Progress•GUI to infer rule-selection

Source-to-Source Transformations

Compiler

•Developing Customization engine

FOCUS: Termination Criteria

Termination Criteria (Hypothesis)• For a mature PLA scenario, considerable performance

improvements can be achieved by using the FOCUS approach

• We will use TAO mature real-time ORB as our gold standard

• Greatest benefits will be accrued for scenarios that can turn on all/most of the optimizations

–Performance improvements estimated ~ 30 – 40 % improvement in performance

• Turning on just one/two optimizations might improve performance by ~ 10 – 15 % improvement

Dissertation Timeline

Fine-grain Componentization

Tools for Configuration

Validation

May 2003 Nov 2004 Nov 2005

Application- Specific

optimizations

Policy-driven approaches for

middleware

MDD Techniques, BGMLSkoll

DOA {2002, 2003}RTAS 2003

ICDCS 2004 Middleware for Communication

ICSR 2004 RTAS 2005, ICSE 2005,

IEEE Software, IJES, Elsevier

RTAS 2004,Springer Real-time

Systems Journal

FOCUS, Specialization

Patterns

Concluding Remarks• This proposal outlined current &

future trends in building customizable middleware for product-line architectures

• It also motivated the need for a continuum of optimizations to address & enhance application QoS

–General-purpose optimizations, that enable customization of middleware for different product-variants

GENERAL PURPOSE OPTIMIZATIONS

VirtualComponent

PatternPatterns Optimization

Patterns

CONFIGURATION DRIVENOPTIMIZATIONS

MDDTechniques Skoll

Design ofExperiments

APPLICATION DRIVENOPTIMIZATIONS

CORBARequestHeader

PrefetchSkeleton

MarshalingElimination

SP

EC

IFIC

ITY

ReactorSpecialization

ProtocolSpecialization

• Research focus can be categorized hierarchically:

Concluding Remarks

–General-purpose optimizations, that enable customization of middleware across different product-variants,

–Configuration-driven optimizations, that enable selection of right configurations for different variants to maximize QoS


VirtualComponent


Patterns


MDDTechniques Skoll



CORBARequestHeader

PrefetchSkeleton


SP

EC

IFIC

ITY




• This proposal outlined current & future trends in building customizable middleware for product-line architectures


Concluding Remarks

–General-purpose optimizations, that enable customization of middleware across different product-variants,

–Configuration-driven optimizations, that enables selection of right configurations for different variants &

–Partial Specialization optimizations, that will customize middleware according to application invariants


VirtualComponent


Patterns


MDDTechniques Skoll



CORBARequestHeader

PrefetchSkeleton


SP

EC

IFIC

ITY




• This proposal outlined current & future trends in building customizable middleware for product-line architectures


Summary of Research ContributionsArea Contributions

General-purpose optimization techniques

• Patterns & techniques for developing fine-grain componentized middleware architectures

• Policy-driven middleware customization approachesConfiguration-driven optimization techniques

• Domain-specific modeling language (DSML) to capture QoS evaluation concerns for component middleware & PLAs

Partial-specialization optimization techniques

• FOCUS: A tool-driven approach for middleware specialization

Preserving & validating middleware configuration properties

• MDD Distributed Continuous Quality Assurance (DCQA) process for preserving & validating middleware configuration properties

• Main-effects screening, which is a DCQA process for identifying middleware configuration main effects

Summary of PublicationsContributions My Publications & Acceptance rates

Fine-grain Componentization of Middleware Architecture

1. Book Chapter: Middleware for Communications, Wiley, NY, 20042. International Conference on Distributed Systems (ICDCS) 2004

(17%)3. Real-time Application Symposium (RTAS) 2003 (25%)4. Distributed Objects & Applications (DOA) 2002 (25%)5. Distributed Objects & Applications (DOA) 2003 (30%)

Middleware Configuration validation & selection

6. International Conference on Software Engineering (ICSE) 2005 (10-15%)

7. RTAS 2005 (30 %)8. International Conference on Software Reuse (ICSR) (22%)9. Elsevier Science of Computer Programming, 10. International Journal of Embedded Systems (Invited submission)11. IEEE Software12. Studia Infomatica Universalis Journal

Benchmarking & Performance evaluation

11. Real-time Application Symposium (RTAS) 2004 (27%) (Selected as Best of RTAS 2004)

12. Springer-Verlag Real-time Systems Journal

First Author Second Author Third Author

Questions?

Arvind S. Krishna [email protected] Institute for Software Integrated Systems

Documents

Transcript of Arvind S. Krishna [email protected] Institute for Software Integrated Systems