assessing contemporary modularization techniques for middleware specialization
DESCRIPTION
Assessing Contemporary Modularization Techniques for Middleware Specialization. Akshay Dabholkar & Aniruddha Gokhale [email protected] OOPSLA ACoM 2008 Workshop Oct 19, 2008. Motivation: Intelligent Transportation Systems. Dynamic and constantly evolving systems - PowerPoint PPT PresentationTRANSCRIPT
1
Assessing Contemporary Modularization Techniques for
Middleware Specialization
Akshay Dabholkar & Aniruddha [email protected]
OOPSLA ACoM 2008 WorkshopOct 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 FeatureOptional 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
5 CUTS6
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
AUGMEN
TATION
PRUNIN
G
COMPUTATIONAL REFLECTION
ASPECT ORIENTED PROGRAMMING (AOP)
MODEL-DRIVEN ENGINEERING (MDE)
TUNABL
E
MUTABL
E
CUSTOM
IZABLE
CONFIG
URABLE
PRE-POSTULATED JUST-IN-TIMELIFECYCLE STAGES
PAR
AD
IGM
-DEP
END
ENT
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-ti me Transparency without affecti ng core
Code Bloati ng 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 cul t to predict runti me conditions , preconceive hooks
AspectOpenORB, DTO
Just-in-time + AOP
Dynamic weaving of features Dynamic Adaptati on Requires native platform support
JAs Co, PROSE, Abacus
Just-in-time + MDE
Sel f-hea l ing/correcti ng systems
Va l idati on of Specia l i zations
Incur runtime overhead Models@Runti me
Just-in-time + Refl ection
Introspect runtime appl icati on features
Dynamic Adaptati on & reconfi gurati on
Can cause unpredictable behavior, preconceive hooks
AspectOpenORB
AOP + FOP ISD and SPLs Better modularization of cros scutti ng features than AOP a lone
Runtime specia l i zations not poss ible, cause confl icts
AFMs, Caes ar
FOP + MDE SPLs Better composition of features
Runtime specia l i zations not poss ible, cause confl icts
FOMDD
AOP + Refl ection Compos ition based on appl icati on requirements
On-demand feature weaving
May cause confl icts AspectOpenORB
AOP + MDE + FOP + Refl ecti on
Des ign/Weave/Prune va l id features combinati ons
Systemati c, correct specia l i zation proces s
Safe specia l i zati ons is 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