1. Architecture-Driven Context-Specific Middleware Specializations for Distributed Real-time and Embedded Systems Akshay Dabholkar, and Aniruddha Gokhale Dept. of EECS, Vanderbilt University, Nashville, TN, USA {aky, gokhale}@dre.vanderbilt.edu Work supported by NSF CAREER Award # 0845789

2. 1. Motivation: Why Specialize Middleware? General-purpose middleware offer a number of features to support a wide range of applications Middleware features are organized into cooperating layers But the rigid layered processing adds time and space overhead In general, the application & middleware design forces are antagonistic

3.  Prune away unnecessary features based on domain requirements, desired configurations, platform constraints and physics of operating environment.  Optimize performance by moving away from the rigid layer processing  Incorporate domain-specific semantics through AOP and FOSD techniques  Correct-by-construction of specialized middleware stacks Middleware Feature Layers 2. What is Middleware Specialization? Key goal: Automation of all stages of specializations RTCORBA Features Processor Resources Communication Resources Memory Resources

4. 3. Impediments to Middleware Specialization Number of How To?s 1.Identification of execution context 2.Inference of the specialization opportunities from the context 3.Selection of specialization points and paths in middleware 4.Realization of the specializations 5.Automate all of the above

5. 4. GAMMA Approach to Middleware Specialization  GAMMA leverages existing system modeling and specialization engines based on FOP/AOP, D&C and runtime weavers  Specializations need to be validated to ensure that they meet the end-to-end requirements of the application.  GAMMA allows pluggability of language-specific transformations as well as middleware platforms Generators and Aspects for Manipulation of Middleware Architectures

6.  Focus on Vertical Decomposition of middleware in terms of Domain Concerns  Savings in Static Footprint  41% reduction  Reduction in source files  64% reduction  Feature Reduction  60-76% reduction 5. Preliminary Results: FORMS Feature-Oriented Reverse Engineering for Middleware Specialization

7. 6. Work In Progress: Deducing Specialization Opportunities from the Context Mapping Ahead of Time (AOT) System Properties to Specialization Directives  Collocation  Remove networking code  Periodicity  Pre-create marshaled Request  Single Interface Operations  Specialize Request Path  Reactor/Protocols  Plug in right reactors (remove indirections) Periodic Timer: Sends same data repeatedly Single method interfaces: Sends same operation on wire Investigating use of  Model Driven Engineering Tools  Profiling and Automated Feedback

8. EXTRAS

9. Group Failover Semantics 2. Motivation: Why Specialize Middleware? Differentiated Services Resource Constrained Real Time updates Specialization (Use Case) Application -specific Reconfigurable Conveyor Belt CPS Intelligent Transportation Systems Direct Application Generalization (Domain)

10. 5. Selection of Specialization Points & Path 1.Middleware Developer can define the specialization points through annotating their design models as well as source code 2.A collection of related specialization points forms the Specialized Path

11. 6. Instrumenting the Specializations 1.Automate creation of specialization rules using design knowledge and specialization paths 2.Automate selection of specialization rules once context is determined