Employing End-to-End Specialization Techniques for Middleware Product-Lines

1. Employing End-to-End Specialization Techniques for Middleware Product-Lines Akshay Dabholkar & Aniruddha Gokhale {aky, gokhale}@dre.vanderbilt.edu OMG RTWS 2008

2. Motivation • Drawbacks with contemporary general-purpose middleware (CORBA, J2EE, .NET) • Performance degradation and increase in memory footprint • Lack of first-class support for domain-specific properties • Oblivious of design-, deployment-, run-time requirements • Lack of extensibility for domain-specific and independent modules

3. Current State of Art • Too proprietary, ad-hoc and custom • Require reinvention of existing solutions, • Expensive to develop and maintain • Hard to evolve • Difficult to test for correctness and QoS • Lack openness and interoperability Billions of losses per year Approaches that address life-cycle issues providing integrated & automated specializations are required

4. Formal representation of features - Origami Matrices • Modules that implement features - Aspects • Promote Automation – Generative Techniques

5. Taxonomy of Middleware Specialization Techniques • Overlapping dimensions share concepts e.g. AOP includes both feature pruning & augmentation and can be used for customization as well as tuning • Can be combined to produce new variants of specialization • Serves as a guideline for synthesis of tools for design, V&V, analysis of specializations How to? What to? When to? • Three dimensional Taxonomy • of • Middleware Specializations

6. Backup Slides

9. Challenge 1: What to specialize? • Context: Resource constrained embedded software require footprint management • Solution:Map application features to the supporting middleware features and optimize the middleware • 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 • Feature Pruning • Traditional middleware provides a broad range of features (generic) for multiple application domains • Remove unessential features • Benefits: reduces footprint, improves performance • e.g. CORBA, COM+, Java RMI Need for consistent and correct feature management

10. Challenge 2: When to specialize? (1/2) • Context: Specializations can span the complete system development cycle • Solution: Static & Dynamic processes and artifacts • Pre-postulated Specialization • Tailors the middleware before knowing its future application requirements • Defines middleware configuration to be used in response to the functional and environmental changes • Customizable • Application compile/link time, after development time • Generates specialized (adapted) application versions • e.g. static aspect weaving, compiler flags, precompiler directives, QuO, EmbeddedJava • Configurable • Application deployment/startup time, after compile time • e.g. CORBA PI, command-line parameters, configuration files (JacORB, ORBacus)

11. Challenge 2: When to specialize? (2/2) • Just-in-time (JIT) Specialization • Identifies the requirements of running applications in response to functional and environmental changes • Tunable • Fixed middleware core • After the startup time but before run time – init / bootstrap time • e.g. Component Configurator & Virtual Component patterns, two-step process (compile time: AOP, run time: Reflection) • Mutable • Most powerful (adaptive) • No concept of fixed middleware core so can evolve into something completely different or unexpected • e.g. MetaSockets, Reflection, Late Composition, dynamic aspect weaving