GAMMA: Generative Aspect Modeling for
Middleware Algorithmics
Aniruddha S. Gokhale
gokhale@dre.vanderbilt.edu
Institute for Software Integrated Systems
Dept. of Electrical Eng & Computer Sc
Vanderbilt University
Nashville, Tennessee
Increasingly Sophisticated & Complex Appln Mix
•
•
Network, hardware and software advances are
fueling the growth of newer, sophisticated and
complex network-centric applications across all
domains
Numerous functional and QoS commonalities
across applications within a domain
– e.g., telecom applications need high reliability,
high throughput, high volume
– e.g., enterprise applns need reliability, security and
transactional guarantees
– e.g., sensor network applications must focus on
energy conservation and improving data
dissemination capabilities
– e.g., scientific applications need strict QoS
guarantees, large storage
Economic & societal forces are forcing applications with same scope, substantial
commonalities and some variabilites to be categorized into software product-lines
Focus on Software Product-line Architectures (PLAs)
Context
•
Need to support product variants in a
family of similar products (i.e., productline)
– e.g., Satellite ISP supports a wide range of
digital TV programming packages and
broadband access with different variations
in the product offerings, such as VPN
•
Market economics do not allow developing
custom solutions => need to leverage
advances in middleware technologies
Product-line Architecture Characteristics [Coplien98]
– Scope, defines the domains or context of the application
• e.g., Satellite or ground-based broadband & television programming provider
– Commonalities, that describe the attributes that are common across all
members of the family
• e.g., packaged offerings on broadband access & television programming
– Variabilities, that describe the attributes unique to the different members of
the family
• e.g., analog versus digital cable, bit rates for download/upload broadband
connectivity
PLA and Product Variant Development Process
Comp
Comp
Comp
Comp
Comp
Deployment Platforms
Standards middleware is a key technology candidate for
supporting and sustaining vision of software product-lines
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
– Model features
– Glue components together
– Synthesize deployment artifacts for
standards middleware platforms, e.g.,
J2EE, .NET, & CORBA
Comp
Comp
Comp
Comp
• PLAs define a framework of
Broadband ISP Software
components that adhere to a
common architectural style with a Component
Repository
clean separation of commonalities
and appropriate provisions for
incorporating variations
• Product variations defined via
VoIP
VPN
content
feature modeling [Czarnecki00]
• Model driven development (MDD) &
domain-specific modeling languages
(DSMLs) are used to:
Middleware Structure & Functionality
Software product-lines need
to be supported on different
hardware & OS
• Problem - direct deployment is
tedious, error-prone, & costly
over lifecycles
There are layers of middleware,
just like there are layers of
networking protocols
Standards-based COTS
middleware helps:
•Control end-to-end resources &
QoS
•Leverage hardware & software
technology advances
•Evolve to new environments &
requirements
•Provide a wide array of reusable,
off-the-shelf developer-oriented
services
Technology Gaps in Middleware for PLAs
•
PLAs have very “focused but
crosscutting” requirements of underlying
middleware infrastructure
–
–
–
–
•
Optimized for the platform
Lean footprint
Efficient configuration & deployment
Support run-time adaptations &
reconfigurations
Standards middleware development &
optimizations philosophy catered to
maintaining “generality, wide
applicability, portability & reusability”
– OS, compiler and hardware independent
– e.g., CORBA, J2EE. .NET
•
These technology gaps are hindering PLA
progress => adverse economic and societal
consequences
Need to tailor and optimize standards middleware for PLAs while
continuing to provide standards compliance, portability and flexibility
Narrowing the Technology Gap
Product-line architecture & product variants
PLA1
PLA2
PLA3
•
PLAK
•
•
•
OS1
OS2
OS3
OSN
HW1
HW2
HW3
HWM
Product-lines and product variants will
need to be deployed on different OShardware-network combinations
Standards middleware will need to be
used to eliminate numerous accidental
complexities dealing with the variability
in OS, hardware & networks
Highly optimized paths through layers
of standard middleware are desired
Optimizations Approach
(1) Design-time
– Specialize for the commonalities
displayed by product-lines
– Configure to address the variabilities
displayed by product variants
(2) Run-time
– Optimize for the product component
reassembly & redeployment variability
incurred due to dynamic adaptations
– Support layer-wise middleware
replacement & update capability
Proposed Research: Applying Generative Aspect
Modeling for Realizing Middleware Algorithmics
Project GAMMA (Generative Aspect Modeling for Middleware Algorithmics)
Middleware
building block
models
GAMMA
product-line
product-variant
commonality
variability
models
models
weaving
middleware specialization engine
generative
transformations
general-purpose
standards middleware
stacks
optimized, specialized middleware stacks
Research Focus
• Investigate the use of modeldriven, aspect-oriented and
generative programming
technologies to synthesize
optimized middleware stacks
for product-line architectures
and their product-variants
Research Thrusts
1. Patterns-guided optimizations via specializations & optimal
configurations of standards middleware for software product-lines
2. Validating the middleware optimizations
3. Automating the middleware optimization & validation process
Thrust #1: Patterns-guided Middleware Algorithmics
P1
Avoid obvious waste in common situations
P2
Shift computation in time
P3
Relax specifications
P4
Leverage other system components
P5
Add hardware to improve performance
P6
Replace inefficient, general-purpose routines
P7
Avoid unnecessary generality
P8
Don’t confuse specification and implementation
P9
Pass information like hints in interfaces
P10
Pass information in protocol headers
P11
Optimize the expected case
P12
Add or exploit state to gain speed
P13
Optimize degrees of freedom
P14
Use special techniques for finite universes
P15
Use algorithmic techniques
•
•
Determine the applicability of
Network Algorithmics [Varghese
05] for Middleware
– Network Algorithmics provides an
informal set of 15 optimization
principle patterns
– Successfully applied to highly
optimize network elements like
routers and web servers
– Investigate the use of applying
middleware algorithmics
systematically for different
product-lines in different domains
The choice of middleware
algorithmics depends on:
– Commonalities in PLA functional
& QoS needs
– Variabilities introduced by product
variants
– Variabilities due to middleware
(re)configurations
– Variabilities due to (re)assembly
and (re)deployment decisions
Approach: Capturing System Invariants (1/2)
Boeing BasicSP Product-line scenario – Representative rate-based application
Example System
Identifying Applicable Algorithmics
• Basic Simple (BasicSP) three component • Use early binding parameters to tailor
Distributed Real-time Embedded (DRE)
middleware
application scenario
• Techniques applied could range from:
• Timer Component – triggers periodic
• Conditional compilation
refresh rates
• Optimized stub/skeleton generation
• GPS Component – generates periodic
• Strategy pattern to handle alternatives
position updates
• Airframe Component – processes input
from the GPS component and feeds to
Program Specialization Invariants
Navigation display
Must hold for all specializations
• Navigation Display – displays GPS
•output(porig) = output (pspl)
position updates
• speed (pspl) > speed(porig)
Approach: Capturing System Invariants (2/2)
Observations about Component Interactions
Periodic
Timer
Single
method
interfaces
Observation:
• Periodic same event message
• Single method interfaces defined on
the component
Observations about Component Deployment
Same
Endianes
s
Collocated
Components
Observation:
• Homogeneous environment
• Collocated components
Mapping Ahead of Time (AOT) System Properties to Specializations
• Periodicity  Pre-create marshaled Request
•
•
•
•
Single Interface Operations  Pre-fetch POA, Servant, Skeleton servicing request
Same Endianess  Avoid de-marshaling (byte order swapping)
Collocated Components  Specialize for target location (remove remoting)
Same operation invoked  Cache CORBA Request header/update arguments only
Preliminary Results: Handcrafted Middleware
Algorithmics in TAO ORB
•
Applying handcrafted middleware algorithmics to TAO ORB for use in
BasicSP product-line scenario
Client Side Specialization
• Request header caching (P11)
• Pre-creating requests (P12)
• Avoid marshaling checks (P1)
• Target location (P11)
1
Client
Server Side Specialization
Cumulative Effect
• More than additive increase of
adding specializations
• For example:
• Client side – request caching
• Server side – specialize
request processing
• 1+1 = 3?
OBJ
REF
4
• Specialized request processing (P7)
• Avoid demarshaling checks (P1)
2
IDL
STUBS
Object
(Servant)
in args
operation()
out args +
return
ORB
INTERFACE
IDL
SKEL
Object Adapter
5
ORB CORE
1
2
3
GIOP/IIOP/ESIOPS
3
Specialization on Location
Request Header
Caching
Eliminate un-necessary
checks
4
Pre-create Request
5
Optimize for Target
Location
Thrust #2: Validating the Middleware Algorithmics
Product-line architecture & product variants
PLA1
PLA2
PLA3
PLAK
BB11
BB21
BBX1
BB12
BB22
BBX2
BB1Y
OS1
HW1
BB2Y
OS2
HW2
OS3
HW3
BBXY
OSN
HWM
• Key Investigations
– Effect of specializations on
standards compliance and
portability
– Evaluation of optimizations on
middleware QoS and footprint
– Validating compatibility across
middleware layers due to:
• Application of middleware
algorithms
• Composition & configuration of
specialized building blocks
• Replacement of individual
building blocks and/or complete
middleware stacks
– Validating consistency of state
across specialized middleware
layers
• e.g., concurrency issues,
priorities, timeouts
Preliminary Validation Results
Optimization
• Cache GIOP
Request
Header part
Performance
Improvements
• Roundtrip
throughput
improved by
~ 50-100
calls/sec
CORBA Compliance
& Automation
• Compliant with
CORBA
specification
• Realized by
macros
• Not much gain by
doing this
Optimization
Performance
Improvements
CORBA Compliance
& Automation
• Cache Request
Header +
Request
Message
• Roundtrip
throughput
improved by
~ 300 – 350
calls/sec (~ 5
%)
• Compliant with
CORBA
specification
(service contexts)
• Latency ~ 3
µsecs (~ 5%)
• Realizable by
using policies at
object level at
client side
Optimization
Performance
Improvements
CORBA Compliance
& Automation
• Code
subsetting –
removed
connection
related code
• libTAO ~ 6%
(100 kB of
reduction)
• Compliant with
CORBA
specification
• Application ~
15 %
• Realized by
macros
• Performance –
elimination of
remoting
checks
• Improved by
10 % (over
and above
Thru_POA)
collocation
• Invocation
classes can be
separated out as
libraries
Optimization
Performance
Improvements
CORBA Compliance
& Automation
• Entire
CORBA
Request
• Avoids
marshaling data
completely
• Not Compliant
with spec
• Can eliminate
multiple layers by
directly sending
request
Promising results indicate the need for
automating the optimization & validation process
• IDL compiler can
pre-create and
generate entire
request
Thrust #3: Automating the Algorithmics & Validation Process
PLA
Middleware
invariants
models
Generative
middleware
specializer
• Vision of an automated
middleware optimization
process for PLAs and product
variants
• Process involves
– Models of middleware and PLA
invariants
– Middleware specialization using
generative programming
Specialized
Product-specific Middleware Product-specific
assembly
deployment
Configuration
variability
variability
model
Variability
Weaver &
generator
Optimized
Middleware
validation
• Applies middleware algorithmics
• Produces specialized middleware
artifacts for PLA commonalities
– Specification of product-specific
configuration & deployment
variability
– Weaver to incorporate product &
middleware specific variability
– Produces optimized middleware
Need to address key crosscutting issues:
– Removing middleware generality
– Optimal configuration & deployment
– Run-time adaptation
Challenges in Algorithmics Automation
Key Questions:
Product-line architecture & product variants
PLA1
PLA2
PLA3
PLAK
•
•
•
•
•
How to define and capture PLA
invariants & product variants?
How to represent middleware models
& its configurability?
How to represent product-specific
functional & QoS variability
How to represent assembly &
deployment-specific variability?
How to represent runtime adaptationspecific variability
Key Observations
•
•
•
•
Patterns: Gang of Four, POSA 1,2 & 3
Middleware comprises a composition &
configuration of patterns-based
building blocks
Observed functionality & QoS depends
on the right composition &
configuration these blocks
PLA deployment concerns will also
drive different middleware layer
compositions and configurations
Run-time conditions can require
reassemblies & redeployments =>
possible changes in optimizations
Opportunities for Algorithmics Automation [1/4]
• Identifying points of commonalities & variabilities drives automation
(1) Per Building Block Scope
Reactor
single
threaded
– Incurred due to variations in implementations
& configurations for a specific patterns-based
building block
thread pool
event handling strategy
select
poll
Qt
WaitForMultipleObjects
Tk
• e.g., single threaded versus thread-pool based
reactor implementation dimension that crosscuts
the event demultiplexing strategy (e.g., select,
poll, WaitForMultipleObjects)
– PLA-specific commonalities help reduce the
configuration choices
event demultiplexing strategy
Reactor_Impl
• e.g., single threaded reactor configuration for
iterative servers
select ()
– Product-specific variabilities identify other
optimization opportunities
Select Reactor
select ()
Thread_Pool
Reactor
select ()
WFMO_Reactor
select ()
• e.g., Reactor specialization by removing
indirection, i.e., remove all virtual methods from
Reactor_Impl base class completely
• No effect on component interfaces.
• Does not break compatibility
Opportunities for Algorithmics Automation [2/4]
• Identifying points of commonalities & variabilities drives automation
(2) Building Block Composition
Scope
– Incurred due to variations in the
compositions of patterns-based
building blocks
– PLA commonalities decide
applicable composition
• e.g., for iterative servers, composing
Leader-Follower with single threaded
Reactor is plain overhead and useless
– Product variabilities help identify fast
paths through the compositions
• e.g., eliminate indirections in compositions
• e.g., eliminate unnecessary lookups
Opportunities for Algorithmics Automation [3/4]
• Identifying points of commonalities & variabilities drives automation
Comp
Comp
Comp
(3) (Re)Assembly Scope
Comp
Comp
– Incurred due to variations in the
(re)assembly (i.e., interconnections) of
product components, which affect
middleware and its optimizations
– PLA commonalities in assembling identify
opportunities for optimization
• e.g., pre-create request headers for
components that periodically interact using
same request type on the same target
• However, run-time adaptations may require
reassembly and hence different optimizations
– Product-specific assembly variabilities
identify more optimization opportunities
• e.g., certain product components may always
interact using private communication
channels or out of band signaling =>
optimize the specific communication path in
the middleware
Opportunities for Algorithmics Automation [4/4]
• Identifying points of commonalities & variabilities drives automation
(de)marshaling
byte order check
Incoming request from
collocated component
Comp
Comp
Request handling
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Deployment Platforms
(4) (Re)Deployment Scope
– Incurred due to variations in the
(re)deployment of product components,
which affects middleware & its
optimizations
– PLA commonalities in deployment
identify opportunities for optimization
• e.g., effective use of OS features & network
protocols and interfaces
• However, run-time adaptations may require
redeployment & reconfiguration of
middleware
– Product-specific deployment variabilities
may identify more optimization
opportunities
• e.g., certain product components must
always be collocated or must be deployed on
homogeneous system => eliminate
unwanted routines, such as marshaling and
byte order checks
Approaches to Algorithmics Automation (1/2)
Key Insights
Per
Building
Block
Block
Composition
(Re)
Assembly
(Re)
Deployment
•
•
middleware
features
commonalities
variabilities
algorithmics
•
•
•
generative
programming
optimized middleware
•
The four scopes illustrate multi
dimensional separation of concerns
[Tarr 99]
Scopes could be represented using
higher levels of abstractions instead of
low level code or platform-specific
artifacts
Layer-wise required middleware
elements are features
Different PLA-specific commonalities
and product-specific variabilities are
aspects (or features), which crosscut
layers of middleware
Applicable middleware algorithmics are
aspects, which crosscut PLA/product
functionality & QoS
Developing optimized middleware
artifacts is then a process of
systematic weaving of all these
aspects using generative
programming
Approaches to Algorithmics Automation (2/2)
Key Investigations of Approaches
•
Per
Building
Block
middleware
features
Block
Composition
commonalities
(Re)
Assembly
variabilities
(Re)
Deployment
•
–
–
–
–
–
algorithmics
•
generative
programming
optimized middleware
Scope representation using domain
specific modeling languages (DSMLs)
Middleware algorithmics using partial
specialization techniques
Code annotations
C++ templates/Java generics
XML metadata-driven
Leveraging Aspect C++/ AspectJ
Synergies with Just-in-time Middleware
[Jacobsen 04], FACET [Cytron 02]
Aspect weaving and code synthesis
– Stepwise refinement and featuredriven synthesis in AHEAD [Batory
03,04,05]
– DSMLs used for representing
different kinds of aspects
– Composition operators to
represent weaving of aspects and
synthesis of middleware
Challenges in Automating the Validation Process
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Comp
Deployment Platforms
• Automating the middleware layerwise configuration & composition
compatibility checks
• Automating the performance
improvement measurements
• Automating the footprint reduction
measurements
• Validating the delivered
functionality and QoS by
optimized middleware
• Validating (re)assembly
connections
• Validating (re)deployment
planning decisions
• Automating standards
compliance checks
Approach to Automating the Validation Process
B
•
OCML
Configuration
Service Information
Config
files
A
Model
D
E
Skoll
– Useful for re(assembly) and
(re)deployment scenarios also
Internet
distribu
Target
syste
ted
Machine
m
•
F
BGML
C
Script
files
IDL
Investigate use of other collaborative
research
– e.g., model checking for compatibility
checks using forward and backward
slicing
– e.g., design-time performability
analysis using stochastic reward nets
& simulations
Benchmark
Information
.cpp
•
Tool-driven approach eliminates
accidental complexities in
configuration evaluation
Empirical validation of delivered QoS
via model-driven generation of
benchmarks
•
Standards compliance to be tested
via existing standards middleware
test suites
Use new ISIS Emulab environment
for testing setup
Preliminary Results: Model-driven Generative
generative
Programming Toolsuite • Used
programming to
Visual Modeling
• Collection of domain-specific modeling languages (DSMLs) to address D&C
concerns
• Based on OMG D&C spec
• Correct-by-construction
• Strong typing &
constraint-checking
• Enhances OMG MDA Vision
• MDD enhances OMG
Model Driven Architecture
(MDA) approach via
DSMLs to support QoSsensitive distributed
systems
• Addressing crosscutting
D&C concerns
• CoSMIC DSMLs enable
untangling D&C
concerns
• Alleviates Accidental
Complexities
• Generative tools to
address low-level
platform-specific
details
weave & synthesize
optimal assembly &
deployment artifacts
for application
components
• Used to optimally
configure middleware
• Used for validation
• Metamodeling
• Uses Generic Modeling
Environment (GME)
metamodeling capabilities
www.dre.vanderbilt.edu/cosmic
Research Impact
• Standards middleware that is optimized for PLAs and their
product variants for both the design-time and run-time needs
• Guidance for next generation middleware development
• Hardening the use of generative programming technologies
General-purpose
optimizations:
Improve performance &
footprint across PLAs
Configuration-driven
optimizations:
Selection and validation
of right middleware
configurations to enhance
QoS for PLA variants
Specialization
Optimizations:
Specializing middleware for
chosen configuration
Case Studies (1/2)
• Two case studies planned with
high educational & research
impact
• Networking Product Line
TO-DO
Figure showcasing
networking scenario
– STILL WORKING ON DEFINING
THIS USE CASE (network
management?, broadband
product-line?)
– Leverage Cisco University
Research Award for BEEP
middleware
– Demonstrate ideas on BEEPACE and BEEP-Java
– Experimental setup on ISIS
Emulab
Case Studies (2/2)
•
TO-DO
Figure showcasing
grid computing
example
Product-line for grid computing
– Focus on dynamic & multilevel resource
management in grid computing
– Choosing a physics scientific
experiment
– Need for dynamic adaptation
capabilities at multiple levels
– Stringent QoS needs for some
application tasks
– Case study will test the optimizations in
resource provisioning and adaptive
middleware
– Leverage collaborations with
FermiLab/Caltech/U of Florida
(MonaLisa and Ultralight projects)
– Leverage Vanderbilt ACCRE cluster
– Leverage Vanderbilt University Award
for research in middleware for grid
computing
Broader Impact
• Research Impact
–
–
–
–
Applicable to all middleware e.g., J2EE, .NET, CORBA
New foundations in model-driven generative programming
Guidance for next generation of middleware development
Useful for communities like ACM Middleware, Usenix NSDI, AOSD, GPCE,
ACM OOPSLA, Grid computing
– Open source tools, broader dissemination, publications
– Alignment with the widely used Eclipse Modeling Framework (EMF)
• Educational impact
– New foundations & tools to drive curricular enhancements (already making
these impacts via use of model-driven development tools in classes)
– Tools will enable active learning in many systems-oriented courses e.g.,
operating systems, distributed systems, networking, aspect oriented design,
control systems
• Industrial Impact
– New technology adoption in PLA development
– Transitions to telecom/networking industry via collaborations and funded
projects (Bell Labs, Cisco, Telcordia), to defense industry via funded projects
(LMCO, BBN),
Concluding Remarks
•
•
Economic and societal forces are playing an important role in the trend towards
software product-lines & their product variants
Many tools & technologies are emerging to encourage this trend
– e.g., Microsoft Corona & DSL tool suite, Eclipse Concern manipulation Environment &
EMF
– e.g., aspect-oriented tools (AspectJ, AspectC++), feature modeling (AHEAD, GenVoca)
•
•
Existing middleware – though optimized – continues to be too general-purpose
since its evolution was guided by forces requiring wide applicability and portability
Our hypothesis that Middleware Algorithmics provides a systems-oriented
patterns-guided approach to optimize middleware for product-lines
– Significant potential to make middleware more suitable for product-line needs
– Can continue to remain standards-compliant
•
Aspects, Model-driven development & generative programming provides the
means to realize these middleware algorithmics for product-line architectures
– e.g., Just-in-time Middleware (U of Toronto), FACET (Washington U) showcase use of
features to drive middleware synthesis
– The GAMMA project investigates the use of middleware algorithmics in conjunction with
feature modeling and generative programming
•
•
•
Our research group has to date worked on the following technologies
www.dre.vanderbilt.edu/cosmic (generative model-driven development toolsuite)
www.dre.vanderbilt.edu/CIAO (QoS-enabled CORBA component middleware)
www.dre.vanderbilt.edu/TAO (CORBA real-time middleware)