Upload
alexander-terry
View
229
Download
0
Tags:
Embed Size (px)
Citation preview
1
Assessing Contemporary Modularization Techniques for
Middleware Specialization
Akshay Dabholkar & Aniruddha [email protected]
OOPSLA ACoM 2008 Workshop
Oct 19, 2008
1
2
Motivation: Intelligent Transportation Systems
Gives rise to disparate middleware specialization needs i.e., minimizing footprint, maximizing throughput, real-time computation, dynamic adaptation to unpredictable runtime changes
Dynamic and constantly evolving systems
Rich in communication and information exchange
Stringent QoS and performance requirements
Invariably require middleware solutions and optimizations
Intelligent Transportation Systems: An example DRE system
Resource Constrained
Real time (customization)
High Performance
Differentiated Services
Real time
High Performance
Differentiated Services
Adaptive to weather
2
3
Challenges in Middleware Specialization
Dynamic middleware-based systems require context specific optimizations and adaptations i.e., middleware specialization
How can we identify these specializations?
Goal is to enable specializations at all stages of development life cycle in an integrated manner.
Layered Middleware
When? What?
3
COMPUTATIONAL REFLECTION
How?
4
Specialization Type
DEVELOPMENT TIME
COMPILE TIME
RUN TIMEDELOYMENT / STARTUP TIME
C ustomizable
Pre-Postulated (S tatic)
Lifetime-Dependent Middleware S pecialization
T unableC onfigurable
J ust-In-T ime (Dynamic)
Mutable
Application Lifetime
INIT TIME
Challenge 1: When to specialize?
Pre-postulated Customizableo compile/link time, after
development timeo Generates specialized versionso e.g. static aspect weaving, compiler
flags, precompiler directives, Configurableo deployment/startup time, after
compile timeo e.g. CORBA PI, command-line
parameters, ORB configuration files
4
Just-in-time (JIT) Tunableo Fixed middleware coreo After the startup time but before run time – init / bootstrap timeo e.g. Component Configurator & Virtual Component patterns, two-step process (compile
time: AOP, run time: Reflection)
Mutableo Most powerful (adaptive)o No concept of fixed middleware core so can
evolve into something completely different or unexpected
o e.g. MetaSockets, Reflection, Late Composition, dynamic aspect weaving
5
Feature Pruning Traditional middleware provides a broad
range of features (generic) for multiple application domains
Remove unessential features Benefits: reduces footprint, improves
performance
Challenge 2: What to specialize?
Feature Augmentation Traditional middleware may not provide
the desired supporting features Add the required features Commonly used by next generation
middleware designed to overcome the limitations of monolithic architectures
Particularly useful to incorporate domain-specific semantics within middleware
Context: Resource constrained embedded software require footprint management
Solution: Map application features to the supporting middleware features and optimize the middleware
Control System
Self Test
ActuatorSensor
Self Test
Assembly
Position Actuator
Position Sensor
Speed Sensor
Internal Memory Size
+ +
Mandatory Feature
Optional Feature
Inclusive OR
+ Feature Cardinality
Need for consistent and correct feature management
5
6
Challenge 3: How to specialize?
Computational Reflection
Ability to introspect, reason about and adapt own behavior without exposing implementation
6
Model-Driven Engineering
PICML
Component Developer
IDL FilesDefine interfaces
1
Model interfaces
Import/Export IDL2
OCML
Domain Expert
Define options and valid configurations
3
Application Model/
Model Application
Application Developer
5CUTS
6
Select Components
Q/A Specialist
Define experiments
7
Generate experiments8
Refine application QoS based on experiments
Benchmark Application9
Associate rules with meta-model elements
4
Integrates MDSD with QoS-enabled component middleware
ClassMethod1 Method1
Pre Code
Post Code
Aspect
AOP for Middleware Specialization Factorization and separation of cross-cutting
concerns from the middleware core Generate customized versions of
middleware for application-specific domains e.g. CORBA Interceptors, Two-step process
(compile time: AOP, run time: Reflection)
7
AUGMENTATION
PRUNING
COMPUTATIONAL REFLECTION
ASPECT ORIENTED PROGRAMMING (AOP)
MODEL-DRIVEN ENGINEERING (MDE)
TUNABLE
MUTABLE
CUSTOMIZABLE
CONFIGURABLE
PRE-POSTULATED JUST-IN-TIMELIFECYCLE STAGES
PA
RA
DIG
M-D
EP
EN
DE
NT
FEATURE-
MANIPULATION
Taxonomy of Middleware Specialization Techniques
Overlapping dimensions share concepts e.g. MDE/AOP includes both feature pruning & augmentation and can be used for customization as well as tuning
Dimensions can be combined to produce new variants of specialization
Serves as a guideline for synthesis of tools for design, V&V, analysis of specializationsThree dimensional Taxonomy
of Middleware Specializations
How?
What?
When?
7
8 8
Assessment of the Taxonomy
COMBINATIONS USE CASES STRENGTHS WEAKNESSES RELATED WORK
Pre-postulated + AOP
Weave/Prune at compi le-time Transparency without affecting core
Code Bloating FACET, CLA, FOCUS, Bypass ing Layers , AspectOpenORB
Pre-postulated + MDE
Weave/Prune only known features
Elegant des ign Runtime specia l i zations not poss ible
DTO, CLA, Modelware
Pre-postulated + Refl ection
Inspect target platform features
Useful during deployment Diffi cult to predict runtime conditions , preconceive hooks
AspectOpenORB, DTO
Just-in-time + AOP
Dynamic weaving of features Dynamic Adaptation Requires native platform support
JAsCo, PROSE, Abacus
Just-in-time + MDE
Sel f-heal ing/correcting systems
Val idation of Specia l i zations
Incur runtime overhead Models@Runtime
Just-in-time + Refl ection
Introspect runtime appl ication features
Dynamic Adaptation & reconfi guration
Can cause unpredictable behavior, preconceive hooks
AspectOpenORB
AOP + FOP ISD and SPLs Better modularization of crosscutti ng features than AOP a lone
Runtime specia l i zations not poss ible, cause confl icts
AFMs, Caesar
FOP + MDE SPLs Better compos ition of features
Runtime specia l i zations not poss ible, cause confl icts
FOMDD
AOP + Refl ection Composition based on appl ication requirements
On-demand feature weaving
May cause confl icts AspectOpenORB
AOP + MDE + FOP + Refl ection
Des ign/Weave/Prune va l id features combinations
Systematic, correct specia l i zation process
Safe specia l i zations i s chal lenging
Research Needed
9
Open Middleware Specialization Research Areas Based on the survey at least four research areas show up:
Specialization of Domain-specific middleware services
Mutable middleware specialization is powerful but a dangerous technique
Application inconsistency caused by overlapping specialization techniques (similar to feature interaction problem in pattern recognition)
No single specialization that can adapt a entire distributed application
→ Safe specializations?
→ V&V of specializations?
→ Integrated specializations?
→ Pattern Languages of Specializations?
An Integrated Tool Suite based on specialization pattern languages to support synthesis, verification and validation of specializations9
10
Thank You!
Questions?
10