Akshay Dabholkar & Aniruddha Gokhale Institute of Software Integrated Systems (ISIS),

1. Middleware Specialization for Product-Lines usingFeature-Oriented Reverse Engineering (FORMS) Akshay Dabholkar & Aniruddha Gokhale Institute of Software Integrated Systems (ISIS), Vanderbilt University, Nashville, TN, USA Contact : aky@dre.vanderbilt.edu International Symposium on Middleware and Network Applications (MNA 2010) Part of ITNG 2010 April 12-14, 2010, Las Vegas, Nevada, USA

2. Case Study: Networked Logging Server Product Line RT-TPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec TPReactor ThreadMgr Signal SchedPara Reactive Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec SelReactor HandleSetBasicTypes TPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec ThreadMgr Signal BasicTypes PPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec Process ProcMgr Signal Iterative Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec Logging Server Product Variants General-purpose Middleware • Different product variants based on their request processing paradigm • Commonalities: • Web based • TCP protocol • File Input Output • Connection Oriented • Serialization • Block based Input Output • Logging Function • Variabilities: (request processing) • Iterative • Reactive • Multithreaded • Thread Pools • Multiprocess • Signaling

3. Motivation: PLE-driven Middleware Specialization Middleware Feature Layers • Needs Modularization along Domain Concerns – Vertical Decomposition • Contemporary General-purpose middleware (CORBA, J2EE) • Focus is on horizontal decomposition into layers • Bottom-up composition using modularized design template • Generic: Well designed for broad applicability to varied product line domains • Feature-rich: Supports flexibility & configurability of non-functional properties, such as security, real-time, FT etc. • However, • Each product variant incurs additional footprint and potential performance overhead due to unwanted features • Excessive features results into additional testing and maintenance costs • Cost of developing proprietary middleware is high • Moreover, • Not developed using top-down PLE composition techniques – Application & Domain Engineering • PLE concerns are tangled across module boundaries

4. FORMS - Overview Map PIM domain concerns to PIM middleware features through user interactive wizard Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware PIM feature model Compute the middleware closure sets for each PSM source hint Compose closure sets into logical feature modules for each individual product variants Synthesize the feature modules into specialized middleware versions

5. Product Line Engineering Requirements Reasoning PIM Middleware Feature Model Feature Mapping Wizard asks interactive questions to the application developer about the application characteristics The wizard traverses it’s internal decision tree to provide optional answers to each question and developer can have single or multiple choice Each answer determines the next set of questions that will be asked Each answer corresponds to a feature selection and subsequently prunes the middleware feature model incrementally

6. FORMS - Overview Map PIM domain concerns to PSM middleware features through user interactive wizard Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware FM Compute the middleware closure sets for each PSM source hint Compose closure sets into a logical feature module for each individual product variant Compose the feature modules into specialized middleware versions

7. PIM Middleware Features to PSM Feature Definitions Extract the features from the pruned Middleware FM Extracted Features ● PIM-PSM Mapping = Source hints (Feature Definitions) Source hints are middleware features on which product variant is directly dependent Source hints are the starting points for finding feature modules Initial Build Configurations are also created using the source hints

8. FORMS - Overview Map PIM domain concerns to PSM middleware features through user interactive wizard Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware FM Compute the middleware closure sets for each PSM source hint Compose closure sets into a logical feature module for each individual product variant Compose the feature modules into specialized middleware versions

9. Closure Computation for a Product Variant Closure Set - Set of dependent feature definitions and implementations that have no dependencies outside the set Middleware Feature Definitions and Implementations are defined by the middleware developer Using the PSM source hints, the dependent feature definitions and implementations are found

10. Closure Computation Algorithm • Input: Product Variant Feature Set, PIM Feature - PSM Definition mapping • Output: Closure set of dependent feature files • For each feature, find its feature definition (source hint) • For each pending source hint • Recursively find feature dependencies (definitions and implementations) • Add newly discovered dependencies to pending set • Stop when pending set is empty • Combine closure sets of all features of the product variant

11. FORMS - Overview Map PIM domain concerns to PSM middleware features through user interactive wizard Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware FM Compute the middleware closure sets for each PSM source hint Compose closure sets into a logical feature module for each individual product variant Compose the feature modules into specialized middleware versions

12. Evaluation of Footprint and Feature Reduction • Original ACE (Adaptive Communication Environment) middleware • 1,388 PSM source files • 436 features • 2,456 KB footprint • Specialized ACE middleware • ~500 PSM source files  64% reduction • ~ 100-175 features  60-76% reduction • ~ 1,500 KB footprint  41% reduction

13. Concluding Remarks • Middleware modules are Tightly Coupled • FORMS provides only Coarse-Grained Decomposition • Fine-Grained Decomposition based on Application Context is needed Forward Engineering though systematic and elegant does not modularize middleware implementations along domain concerns Reverse Engineering techniques based on source code analysis offer a promising and viable alternative to modularize domain concerns within middleware code. FORMS can lend useful insights into existing middleware modularization by pointing the discrepancies in the number of features desired and the number of source files required to implement them.

14. Questions?