1. 1 Middleware Specialization for Product-Lines using Feature-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. 2 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 Case Study: Networked Logging Server Product Line  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 General-purpose Middleware Reactive Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec SelReactor HandleSet BasicTypes Reactive Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec SelReactor HandleSet BasicTypes TPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec ThreadMgr Signal BasicTypes TPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec ThreadMgr Signal BasicTypes RT-TPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec TPReactor ThreadMgr Signal SchedPara RT-TPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec TPReactor ThreadMgr Signal SchedPara PPC Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec Process ProcMgr Signal 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 Iterative Logging Internet TCP File IO Acceptor Connector CDR MsgBlock LogMsg LogRec Logging Server Product Variants

3. 3 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 Motivation: PLE-driven Middleware Specialization  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 Needs Modularization along Domain Concerns – Vertical Decomposition Middleware Feature Layers

4. 4 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 FORMS - Overview 1.Map PIM domain concerns to PIM middleware features through user interactive wizard 2.Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware PIM feature model 3.Compute the middleware closure sets for each PSM source hint 4.Compose closure sets into logical feature modules for each individual product variants 5.Synthesize the feature modules into specialized middleware versions

5. 5 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 Product Line Engineering Requirements Reasoning  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 PIM Middleware Feature Model

6. 6 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 FORMS - Overview 1.Map PIM domain concerns to PSM middleware features through user interactive wizard 2.Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware FM 3.Compute the middleware closure sets for each PSM source hint 4.Compose closure sets into a logical feature module for each individual product variant 5.Compose the feature modules into specialized middleware versions

7. 7 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 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. 8 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 FORMS - Overview 1.Map PIM domain concerns to PSM middleware features through user interactive wizard 2.Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware FM 3.Compute the middleware closure sets for each PSM source hint 4.Compose closure sets into a logical feature module for each individual product variant 5.Compose the feature modules into specialized middleware versions

9. 9 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 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. 10 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 Closure Computation Algorithm  Input: Product Variant Feature Set, PIM Feature - PSM Definition mapping  Output: Closure set of dependent feature files 1.For each feature, find its feature definition (source hint) A.For each pending source hint I.Recursively find feature dependencies (definitions and implementations) II.Add newly discovered dependencies to pending set B.Stop when pending set is empty 2.Combine closure sets of all features of the product variant

11. 11 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 FORMS - Overview 1.Map PIM domain concerns to PSM middleware features through user interactive wizard 2.Determine the PSM middleware feature definitions (source hints) that correspond to the pruned middleware FM 3.Compute the middleware closure sets for each PSM source hint 4.Compose closure sets into a logical feature module for each individual product variant 5.Compose the feature modules into specialized middleware versions

12. 12 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 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. 13 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 Concluding Remarks  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.  Middleware modules are Tightly Coupled  FORMS provides only Coarse- Grained Decomposition Fine-Grained Decomposition based on Application Context is needed

14. 14 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 Questions?

15. 15 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 State of Art: Middleware Specialization Research  Forward Engineering  AHEAD, CIDE, FOMDD  Rely on manual identification of features in source  FORMS enables automatic identification of coarse-grained features  Can be integrated with FORMS  FACET (Cytron et. al.)  Requires manual refactoring of core functionalities and additional crosscutting functionality into aspects  FORMS automates detection of features and their dependencies  Modelware (Zhang et. al.)  Uses models and views to separate essential, invariant middleware core or intrinsic base view from domain variations or extrinsic or aspect view  FORMS does not differentiate functional and non-functional concerns  Reverse Engineering  Pattern Mining  Relies on discovery of design patterns and frameworks  Informal and substandard due to variations in pattern implementations  FORMS does not rely on discovering framework and design structures  FORMS uses features to drive the detection of feature modules through source code reverse engineering

16. 16 Akshay Dabholkar et al. FORMS for Product Line EngineeringITNG 2010 System Type? ServerClient-ServerP2P Request Handling? Iterative Mechanism? Strategy? Threads ConcurrentReactive Process On-demandEager Data Delivery? SynchronousAsynchronous CallbackPolling Notification?Synchronization? M.E.Locking Strategy? Read-WriteScoped Priority? FIFORR