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
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
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)
•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
A/V 8-Bproductvariant
F/A 18productvariant UCAV
productvariant
Product-line architecture
Hardware (CPU, Memory, I/O)OS & Network Protocols
Customized Middleware
Motivation
•Middleware factors out many reusable general-purpose & domain-specific services from traditional DRE application responsibility •Essential for product-line architectures (PLAs)
•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
Hardware (CPU, Memory, I/O)OS & Network Protocols
Host Infrastructure MiddlewareDistribution Middleware
Common Middleware ServicesDomain-specific Services
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
Hardware (CPU, Memory, I/O)OS & Network Protocols
Host Infrastructure MiddlewareDistribution Middleware
Common Middleware ServicesDomain-specific Services
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
Specialization Techniques Dissertation Timeline Concluding Remarks
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
Presentation Road Map Technology Context Research Challenges Related Research Research Progress Proposed Work Middleware
Specialization Techniques Dissertation Timeline Concluding Remarks
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
ApplicabilityGeneral Specific
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
ApplicabilityGeneral Specific
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
ApplicabilityGeneral Specific
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
Presentation Road Map Technology Context Research Challenges Related Research Research Progress Proposed Work Middleware
Specialization Techniques Dissertation Timeline Concluding Remarks
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]
Presentation Road Map Technology Context Research Challenges Related Research Research Progress Proposed Work Middleware
Specialization Techniques Dissertation Timeline Concluding Remarks
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)
in argsoperation()out args +
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)
in argsoperation()out args +
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
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)
in argsoperation()out args +
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
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
in argsoperation()out args +
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
Presentation Road Map Technology Context Research Challenges Related Research Research Progress Proposed Work Middleware
Specialization Techniques Dissertation Timeline Concluding Remarks
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
Presentation Road Map Technology Context Research Challenges Related Research Research Progress Proposed Work Middleware
Specialization Techniques Dissertation Timeline Concluding Remarks
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
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:
• 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
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
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:
• 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
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?