GAMMA: Generative Aspect Modeling for Middleware Algorithmics

1. Aniruddha S. Gokhale gokhale@dre.vanderbilt.edu Institute for Software Integrated Systems Dept. of Electrical Eng & Computer Sc Vanderbilt University Nashville, Tennessee GAMMA: Generative Aspect Modeling for Middleware Algorithmics

2. Increasingly Sophisticated & Complex Appln Mix • Network, hardware and software advances are fueling the growth of newer, sophisticated and complex network-centric applications across all domains • Numerous functional and QoS commonalities across applications within a domain • e.g., telecom applications need high reliability, high throughput, high volume • e.g., enterprise applns need reliability, security and transactional guarantees • e.g., sensor network applications must focus on energy conservation and improving data dissemination capabilities • e.g., scientific applications need strict QoS guarantees, large storage Economic & societal forces are forcing applications with same scope, substantial commonalities and some variabilites to be categorized into software product-lines

3. Focus on Software Product-line Architectures (PLAs) Context • Need to support product variants in a family of similar products (i.e., product-line) • e.g., Satellite ISP supports a wide range of digital TV programming packages and broadband access with different variations in the product offerings, such as VPN • Market economics do not allow developing custom solutions => need to leverage advances in middleware technologies Product-line Architecture Characteristics [Coplien98] • Scope, defines the domains or context of the application • e.g., Satellite or ground-based broadband & television programming provider • Commonalities, that describe the attributes that are common across all members of the family • e.g., packaged offerings on broadband access & television programming • Variabilities, that describe the attributes unique to the different members of the family • e.g., analog versus digital cable, bit rates for download/upload broadband connectivity

4. Component Repository Comp Comp Comp Comp Comp Comp Comp Comp Comp VoIP VPN content Comp Comp Comp Comp Comp Comp Comp Comp Comp Comp Deployment Platforms PLA and Product Variant Development Process • PLAs define a framework of components that adhere to a common architectural style with a clean separation of commonalities and appropriate provisions for incorporating variations Broadband ISP Software • Product variations defined via feature modeling [Czarnecki00] • Model driven development (MDD) & domain-specific modeling languages (DSMLs) are used to: • Model features • Glue components together • Synthesize deployment artifacts for standards middleware platforms, e.g., J2EE, .NET, & CORBA Standards middleware is a key technology candidate for supporting and sustaining vision of software product-lines

5. & OS Middleware Structure & Functionality Software product-lines need to be supported on different hardware • Problem - direct deployment is tedious, error-prone, & costly over lifecycles There are layers of middleware, just like there are layers of networking protocols • Standards-based COTS middleware helps: • Control end-to-end resources & QoS • Leverage hardware & software technology advances • Evolve to new environments & requirements • Provide a wide array of reusable, off-the-shelf developer-oriented services

6. Technology Gaps in Middleware for PLAs • PLAs have very “focused but crosscutting” requirements of underlying middleware infrastructure • Optimized for the platform • Lean footprint • Efficient configuration & deployment • Support run-time adaptations & reconfigurations • Standards middleware development & optimizations philosophy catered to maintaining “generality, wide applicability, portability & reusability” • OS, compiler and hardware independent • e.g., CORBA, J2EE. .NET • These technology gaps are hindering PLA progress => adverse economic and societal consequences Need to tailor and optimize standards middleware for PLAs while continuing to provide standards compliance, portability and flexibility

7. Product-line architecture & product variants PLA1 PLA2 PLA3 PLAK OS1 OS2 OS3 OSN HW1 HW2 HW3 HWM Narrowing the Technology Gap • Product-lines and product variants will need to be deployed on different OS-hardware-network combinations • Standards middleware will need to be used to eliminate numerous accidental complexities dealing with the variability in OS, hardware & networks • Highly optimized paths through layers of standard middleware are desired • Optimizations Approach (1) Design-time • Specialize for the commonalities displayed by product-lines • Configure to address the variabilities displayed by product variants (2) Run-time • Optimize for the product component reassembly & redeployment variability incurred due to dynamic adaptations • Support layer-wise middleware replacement & update capability

8. Proposed Research: Applying Generative Aspect Modeling for Realizing Middleware Algorithmics Project GAMMA (Generative Aspect Modeling for Middleware Algorithmics) Research Thrusts • Patterns-guided optimizations via specializations & optimal configurations of standards middleware for software product-lines • Validating the middleware optimizations • Automating the middleware optimization & validation process Research Focus • Investigate the use of model-driven, aspect-oriented and generative programming technologies to synthesize optimized middleware stacks for product-line architectures and their product-variants

9. Thrust #1: Patterns-guided Middleware Algorithmics • Determine the applicability of Network Algorithmics [Varghese 05] for Middleware • Network Algorithmics provides an informal set of 15 optimization principle patterns • Successfully applied to highly optimize network elements like routers and web servers • Investigate the use of applying middleware algorithmics systematically for different product-lines in different domains • The choice of middleware algorithmics depends on: • Commonalities in PLA functional & QoS needs • Variabilities introduced by product variants • Variabilities due to middleware (re)configurations • Variabilities due to (re)assembly and (re)deployment decisions

10. Approach: Capturing System Invariants (1/2) Example System • Basic Simple (BasicSP) three component Distributed Real-time Embedded (DRE) application scenario • Timer Component – triggers periodic refresh rates • GPS Component – generates periodic position updates • Airframe Component – processes input from the GPS component and feeds to Navigation display • Navigation Display – displays GPS position updates Boeing BasicSP Product-line scenario – Representative rate-based application Identifying Applicable Algorithmics • Use early binding parameters to tailor middleware • Techniques applied could range from: • Conditional compilation • Optimized stub/skeleton generation • Strategy pattern to handle alternatives • Program Specialization Invariants • Must hold for all specializations • output(porig) = output (pspl) • speed (pspl) > speed(porig)

11. Approach: Capturing System Invariants (2/2) Observations about Component Interactions Observations about Component Deployment Same Endianess Periodic Timer Single method interfaces Collocated Components Observation: • Periodic same event message • Single method interfaces defined on the component Observation: • Homogeneous environment • Collocated components • Mapping Ahead of Time (AOT) System Properties to Specializations • Periodicity  Pre-create marshaled Request • Single Interface Operations  Pre-fetch POA, Servant, Skeleton servicing request • Same Endianess  Avoid de-marshaling (byte order swapping) • Collocated Components  Specialize for target location (remove remoting) • Same operation invoked  Cache CORBA Request header/update arguments only

12. Preliminary Results: Handcrafted Middleware Algorithmics in TAO ORB • Applying handcrafted middleware algorithmics to TAO ORB for use in BasicSP product-line scenario • Client Side Specialization • Request header caching (P11) • Pre-creating requests (P12) • Avoid marshaling checks (P1) • Target location (P11) • Server Side Specialization • Specialized request processing (P7) • Avoid demarshaling checks (P1) • Cumulative Effect • More than additive increase of adding specializations • For example: • Client side – request caching • Server side – specialize request processing • 1+1 = 3?

13. Product-line architecture & product variants PLA1 PLA2 PLA3 PLAK BBX1 BB11 BB21 BB12 BB22 BBX2 BB2Y BBXY BB1Y OS1 OS2 OS3 OSN HW1 HW2 HW3 HWM Thrust #2: Validating the Middleware Algorithmics • Key Investigations • Effect of specializations on standards compliance and portability • Evaluation of optimizations on middleware QoS and footprint • Validating compatibility across middleware layers due to: • Application of middleware algorithms • Composition & configuration of specialized building blocks • Replacement of individual building blocks and/or complete middleware stacks • Validating consistency of state across specialized middleware layers • e.g., concurrency issues, priorities, timeouts

14. Preliminary Validation Results Promising results indicate the need for automating the optimization & validation process

15. Thrust #3: Automating the Algorithmics & Validation Process PLA invariants Middleware models • Vision of an automated middleware optimization process for PLAs and product variants • Process involves • Models of middleware and PLA invariants • Middleware specialization using generative programming • Applies middleware algorithmics • Produces specialized middleware artifacts for PLA commonalities • Specification of product-specific configuration & deployment variability • Weaver to incorporate product & middleware specific variability • Produces optimized middleware Generative middleware specializer Specialized Middleware Configuration model Product-specific assembly variability Product-specific deployment variability Variability Weaver & generator Optimized Middleware Need to address key crosscutting issues: • Removing middleware generality • Optimal configuration & deployment • Run-time adaptation validation

16. Product-line architecture & product variants PLA1 PLA2 PLA3 PLAK Challenges in Algorithmics Automation Key Questions: • How to define and capture PLA invariants & product variants? • How to represent middleware models & its configurability? • How to represent product-specific functional & QoS variability • How to represent assembly & deployment-specific variability? • How to represent runtime adaptation-specific variability Key Observations • Middleware comprises a composition & configuration of patterns-based building blocks • Observed functionality & QoS depends on the right composition & configuration these blocks • PLA deployment concerns will also drive different middleware layer compositions and configurations • Run-time conditions can require reassemblies & redeployments => possible changes in optimizations Patterns: Gang of Four, POSA 1,2 & 3

17. Reactor_Impl select () Select Reactor WFMO_Reactor Thread_Pool Reactor select () select () select () Opportunities for Algorithmics Automation [1/4] • Identifying points of commonalities & variabilities drives automation (1) Per Building Block Scope • Incurred due to variations in implementations & configurations for a specific patterns-based building block • e.g., single threaded versus thread-pool based reactor implementation dimension that crosscuts the event demultiplexing strategy (e.g., select, poll, WaitForMultipleObjects) • PLA-specific commonalities help reduce the configuration choices • e.g., single threaded reactor configuration for iterative servers • Product-specific variabilities identify other optimization opportunities • e.g., Reactor specialization by removing indirection, i.e., remove all virtual methods from Reactor_Impl base class completely • No effect on component interfaces. • Does not break compatibility

18. Opportunities for Algorithmics Automation [2/4] • Identifying points of commonalities & variabilities drives automation (2) Building Block Composition Scope • Incurred due to variations in the compositions of patterns-based building blocks • PLA commonalities decide applicable composition • e.g., for iterative servers, composing Leader-Follower with single threaded Reactor is plain overhead and useless • Product variabilities help identify fast paths through the compositions • e.g., eliminate indirections in compositions • e.g., eliminate unnecessary lookups

19. Comp Comp Comp Comp Comp Opportunities for Algorithmics Automation [3/4] • Identifying points of commonalities & variabilities drives automation (3) (Re)Assembly Scope • Incurred due to variations in the (re)assembly (i.e., interconnections) of product components, which affect middleware and its optimizations • PLA commonalities in assembling identify opportunities for optimization • e.g., pre-create request headers for components that periodically interact using same request type on the same target • However, run-time adaptations may require reassembly and hence different optimizations • Product-specific assembly variabilities identify more optimization opportunities • e.g., certain product components may always interact using private communication channels or out of band signaling => optimize the specific communication path in the middleware

20. Comp Comp Comp Comp Comp Comp Comp Comp Comp Comp Request handling (de)marshaling byte order check Incoming request from collocated component Deployment Platforms Opportunities for Algorithmics Automation [4/4] • Identifying points of commonalities & variabilities drives automation (4) (Re)Deployment Scope • Incurred due to variations in the (re)deployment of product components, which affects middleware & its optimizations • PLA commonalities in deployment identify opportunities for optimization • e.g., effective use of OS features & network protocols and interfaces • However, run-time adaptations may require redeployment & reconfiguration of middleware • Product-specific deployment variabilities may identify more optimization opportunities • e.g., certain product components must always be collocated or must be deployed on homogeneous system => eliminate unwanted routines, such as marshaling and byte order checks

21. Per Building Block Block Composition (Re) Assembly (Re) Deployment middleware features commonalities variabilities algorithmics Approaches to Algorithmics Automation (1/2) Key Insights • The four scopes illustrate multi dimensionalseparation of concerns [Tarr 99] • Scopes could be represented using higher levels of abstractions instead of low level code or platform-specific artifacts • Layer-wise required middleware elements are features • Different PLA-specific commonalities and product-specific variabilities are aspects (or features), which crosscut layers of middleware • Applicable middleware algorithmics are aspects, which crosscut PLA/product functionality & QoS • Developing optimized middleware artifacts is then a process of systematic weaving of all these aspects using generative programming generative programming optimized middleware

22. Per Building Block Block Composition (Re) Assembly (Re) Deployment middleware features commonalities variabilities algorithmics Approaches to Algorithmics Automation (2/2) Key Investigations of Approaches • Scope representation using domain specific modeling languages (DSMLs) • Middleware algorithmics using partial specialization techniques • Code annotations • C++ templates/Java generics • XML metadata-driven • Leveraging Aspect C++/ AspectJ • Synergies with Just-in-time Middleware [Jacobsen 04], FACET [Cytron 02] • Aspect weaving and code synthesis • Stepwise refinement and feature-driven synthesis in AHEAD [Batory 03,04,05] • DSMLs used for representing different kinds of aspects • Composition operators to represent weaving of aspects and synthesis of middleware generative programming optimized middleware

23. Comp Comp Comp Comp Comp Comp Comp Comp Comp Comp Deployment Platforms Challenges in Automating the Validation Process • Automating the middleware layer-wise configuration & composition compatibility checks • Automating the performance improvement measurements • Automating the footprint reduction measurements • Validating the delivered functionality and QoS by optimized middleware • Validating (re)assembly connections • Validating (re)deployment planning decisions • Automating standards compliance checks

24. Approach to Automating the Validation Process • Empirical validation of delivered QoS via model-driven generation of benchmarks • Useful for re(assembly) and (re)deployment scenarios also • Investigate use of other collaborative research • e.g., model checking for compatibility checks using forward and backward slicing • e.g., design-time performability analysis using stochastic reward nets & simulations • Standards compliance to be tested via existing standards middleware test suites • Use new ISIS Emulab environment for testing setup Tool-driven approach eliminates accidental complexities in configuration evaluation

25. Preliminary Results: Model-driven Generative Programming Toolsuite • Used generative programming to weave & synthesize optimal assembly & deployment artifacts for application components • Used to optimally configure middleware • Used for validation • Visual Modeling • Collection of domain-specific modeling languages (DSMLs) to address D&C concerns • Based on OMG D&C spec • Correct-by-construction • Strong typing & constraint-checking • Enhances OMG MDA Vision • MDD enhances OMG Model Driven Architecture (MDA) approach via DSMLs to support QoS-sensitive distributed systems • Addressing crosscutting D&C concerns • CoSMIC DSMLs enable untangling D&C concerns • Metamodeling • Uses Generic Modeling Environment (GME) metamodeling capabilities • Alleviates Accidental Complexities • Generative tools to address low-level platform-specific details www.dre.vanderbilt.edu/cosmic

26. Research Impact • Standards middleware that is optimized for PLAs and their product variants for both the design-time and run-time needs • Guidance for next generation middleware development • Hardening the use of generative programming technologies General-purpose optimizations: Improve performance & footprint across PLAs Configuration-driven optimizations: Selection and validation of right middleware configurations to enhance QoS for PLA variants Specialization Optimizations: Specializing middleware for chosen configuration

27. Case Studies (1/2) • Two case studies planned with high educational & research impact • Networking Product Line • STILL WORKING ON DEFINING THIS USE CASE (network management?, broadband product-line?) • Leverage Cisco University Research Award for BEEP middleware • Demonstrate ideas on BEEP-ACE and BEEP-Java • Experimental setup on ISIS Emulab TO-DO Figure showcasing networking scenario

28. Case Studies (2/2) • Product-line for grid computing • Focus on dynamic & multilevel resource management in grid computing • Choosing a physics scientific experiment • Need for dynamic adaptation capabilities at multiple levels • Stringent QoS needs for some application tasks • Case study will test the optimizations in resource provisioning and adaptive middleware • Leverage collaborations with FermiLab/Caltech/U of Florida (MonaLisa and Ultralight projects) • Leverage Vanderbilt ACCRE cluster • Leverage Vanderbilt University Award for research in middleware for grid computing TO-DO Figure showcasing grid computing example

29. Broader Impact • Research Impact • Applicable to all middleware e.g., J2EE, .NET, CORBA • New foundations in model-driven generative programming • Guidance for next generation of middleware development • Useful for communities like ACM Middleware, Usenix NSDI, AOSD, GPCE, ACM OOPSLA, Grid computing • Open source tools, broader dissemination, publications • Alignment with the widely used Eclipse Modeling Framework (EMF) • Educational impact • New foundations & tools to drive curricular enhancements (already making these impacts via use of model-driven development tools in classes) • Tools will enable active learning in many systems-oriented courses e.g., operating systems, distributed systems, networking, aspect oriented design, control systems • Industrial Impact • New technology adoption in PLA development • Transitions to telecom/networking industry via collaborations and funded projects (Bell Labs, Cisco, Telcordia), to defense industry via funded projects (LMCO, BBN),

30. Concluding Remarks • Economic and societal forces are playing an important role in the trend towards software product-lines & their product variants • Many tools & technologies are emerging to encourage this trend • e.g., Microsoft Corona & DSL tool suite, Eclipse Concern manipulation Environment & EMF • e.g., aspect-oriented tools (AspectJ, AspectC++), feature modeling (AHEAD, GenVoca) • Existing middleware – though optimized – continues to be too general-purpose since its evolution was guided by forces requiring wide applicability and portability • Our hypothesis that Middleware Algorithmics provides a systems-oriented patterns-guided approach to optimize middleware for product-lines • Significant potential to make middleware more suitable for product-line needs • Can continue to remain standards-compliant • Aspects, Model-driven development & generative programming provides the means to realize these middleware algorithmics for product-line architectures • e.g., Just-in-time Middleware (U of Toronto), FACET (Washington U) showcase use of features to drive middleware synthesis • The GAMMA project investigates the use of middleware algorithmics in conjunction with feature modeling and generative programming Our research group has to date worked on the following technologies • www.dre.vanderbilt.edu/cosmic (generative model-driven development toolsuite) • www.dre.vanderbilt.edu/CIAO (QoS-enabled CORBA component middleware) • www.dre.vanderbilt.edu/TAO (CORBA real-time middleware)