1 Middleware Specialization using Aspect-Oriented Programming Dimple Kaul, Aniruddha Gokhale Institute for Software Integrated Systems, Dept. of Electrical Eng & Computer Sc Vanderbilt University, Nashville, Tennessee March 10 th 2006 ACM SE 2006 Conference, Melbourne, FL *Work supported in part by NSF CSR SMA grant

2 Problem & Motivation General-purpose middleware implementations satisfy a broad range of applicability & portability Product-line Variant General-purpose MiddlewareSpecialized Middleware Transform Hardware (CPU, Memory, I/O) OS & Network Protocols Host Infrastructure Middleware Distribution Middleware Common Middleware Services Domain-specific Services Product line architecture’s are driven by the functional & QoS requirements of each product variant Wide range of generality & flexibility results in excessive overheads How to resolve this overhead? Automate specialization Hardware (CPU, Memory, I/O) OS & Network Protocols Specialized Middleware

3 1.Remoting functionality for collocated objects -Bypasses I/O subsystem 2.Marshaling/demarshaling checks -byte order Little endian, big endian 3.Overly Extensible -Transport protocol (TCP, UDP, or Shared memory) -Concurrency model (single-threaded, thread pool, thread-per-connection ) 4.Request creation &/or initialization -Operation name -Message size -Service context 5.Generality of deployment platform -Heterogeneous/homogenous environment Factors Affecting QoS in Middleware Need to tailor & optimize standards middleware for PLAs while also supporting standards compliance, portability, & flexibility Same for an event

4 Solution: Specialization techniques Traditional specialization techniques include: Code refactoring Ahead-of-time design Modern specialization techniques: Feature-Oriented Programming – Incremental stepwise refinement Aspect-Oriented Programming – Separating Crosscutting concerns Aspect Oriented Programming (AOP) shows great promise in specialization of middleware: Functionality can often be changed without refactoring code No need for knowing “ahead of time” functionality Components can be integrated incrementally Weaves an aspect by source-to-source translation at compile time Aspect Oriented Programming languages include AspectC++, AspectJ, & JBOSS AOP But have shortcomings: Manual & Error prone High Memory consumption Performance overhead

5 Overview of Aspect Oriented Programming (AOP) Need to Separate crosscutting concerns -Addresses each concern with minimal coupling -Concerns are stored in modules called aspects -Reduces/prevents code clutter, tangling & scattering Allows adding aspectual code, which does not directly fit into a component Easy to add new functionality by creating new aspects More code reuse & no worry of under/over design Aspect Requirement Aspect Requirement (b) Aspect Oriented Model Class Requirement (a) Object Oriented Model Requirement is dependent on multiple classes “[...] In programs P, whenever condition C arises, perform action A” Each requirement can have separate aspect

6 Specialization of Middleware Middleware consists of different building blocks Each building block can be represented as pattern Patterns are standard solutions & naming conventions to common problems Out of these building blocks we are going to concentrate on Reactor pattern for specialization

7 Reactor Pattern It separates the event detection, demultiplexing & dispatching to application defined event handlers Allows a single thread to handle all these activities for many clients Handle owns dispatches * notifies * * handle set Reactor handle_events() register_handler() remove_handler() Event Handler handle_event () get_handle() Concrete Event Handler A handle_event () get_handle() Concrete Event Handler B handle_event () get_handle() Synchronous Event Demuxer select () > Reactor_Impl select () Select Reactor select () WFMO_Reactor WaitForMultipleObjects( ) Thread_Pool Reactor select () ACE middleware framework supports several implementations of the Reactor pattern, e.g., - ACE_Select_Reactor - single-threaded event demultiplexer - ACE_TP_Reactor - multi-threaded event demultiplexer - ACE_WFMO_Reactor - windows event demultiplexer

8 To work transparently across all reactor implementations, ACE uses Reactor_Impl abstract base class that delegates to subclasses using virtual method calls & the Bridge pattern Using AOP application specific reactor implementation method is called directly Generality penalty is eliminated by removing the indirections Middleware supports multiple types of Reactor implementations but a particular product variant may need only one implementation Reactor Specialization Using AOP Product Line1Product Line 2Product Line 3 Select Reactor select () Reactor_Impl select () WFMO_Reactor WaitForMultipleObjects( ) Thread_Pool Reactor select () Applied specialization of two reactor implementations: Select Reactor Thread Pool Reactor

9 Reactor Specialization Using AOP Using AOP specialization techniques we can select a particular reactor implementation AspectC++ can remove indirection e.g., virtual method calls in Reactor_ Impl are eliminated Select Reactor Specialization: aspect Single_Thread_Implementation { advice call ("% ACE_Reactor_Impl ::purge_pending_notifications(...)"):around () { ((ACE_Select_Reactor_Impl *) tjp->target ())-> ACE_Select_Reactor_Impl ::purge_pending_notifications (*tjp->arg (), *tjp->arg ()); } ThreadPool Reactor Specialization: aspect Thread_Pool_Implementation { advice call ("% ACE_Reactor_Impl ::handle_events(int)"):around () { ((ACE_TP_Reactor *) tjp->target ())-> ACE_TP_Reactor::handle_events (*tjp->arg ()); } On call of ACE_Reactor_Impl method in execution flow, replace with ACE_Select_Reactor method On call of ACE_Reactor_Impl method in execution flow, replace it with ACE_TP_Reactor method AOP separation of concerns helps remove middleware generality advice: Specifies what code should run around: advice body is executed instead of control flow

10 Experiment Setup & Configuration System configuration: OS Version: Red Hat Linux 9 with kernel version Model:Intel Pentium CPU Speed/Memory:2.7 GHz/1GB RAM Cache size:1 MB Test run: $ACE_ROOT/TAO/performance-tests/Latency/* Used Real-Time scheduling class Following tests were conducted to ensure correctness & performance improvement: Latency & roundtrip throughput test for Single threaded application Multi-threaded client & server

11 Experimental Results (1/2) ACE middleware framework configured with ACE_Select_Reactor (single-threaded implementation of Reactor) using aspects Assumption: Application only requires single- threaded functionality Note: Rest of the code path is not changed Average latency of system improved by ~3% Average roundtrip throughput of system improved by ~2% # of iterations: 100,000

12 Experimental Results (2/2) ACE middleware framework configured with ACE_TP_Reactor (thread pool concurrency model having multi-threaded implementation of Reactor) using aspects Assumption: Application only requires multi- threaded functionality Note: Rest of the code path is not changed Average roundtrip throughput of system improved by ~3% Average latency of system improved by ~4% # of iterations: 150,000

13 Related Work (Feature Oriented Customizer ) Feature Oriented Customizer (FOCUS) is a domain-specific language developed to automate specialization of middleware via two steps: –Identifying specialization points & transformations –Automating the delivery of the specializations Normal C++ compiler is used to compile code Specialized Middleware General Middleware with hooks Customization engine transforms annotations //File: Reactor.h REACTOR_SPL_INCLUDE_HOOK class Reactor { public: virtual int run_reactor_event_loop (REACTOR_EVENT_HOOK = 0); // Other public methods.... private: ACE_Reactor_Impl *reactor_impl_; // }; //File: Reactor.h REACTOR_SPL_INCLUDE_HOOK // Code woven by FOCUS: #include "ace/Select_Reactor.h" // END Code woven by FOCUS class Reactor { public: int run_reactor_event_loop (REACTOR_EVENT_HOOK = 0); // Other public methods.... private: // Code woven by FOCUS: ACE_Select_Reactor *reactor_impl_; // End Code woven by FOCUS // };

14 Observations Pros Performance improved with increase in number of specializations AspectC++ is like AspectJ in syntax & semantics, so it’s easy to port specialization files from C++ to Java Well-suited for automated program instrumentation -Monitoring of software systems -Binding of aspect is independent of current development stage We expect an additive increase in performance when we implement this specialization for other QoS challenges Cons AOP requires recompilation of source & their was acceptable size increase of executable by around 0.09% Many features are not available in current version of AspectC++ -No flexible way to describe the target components -Doesn’t transform macro- generated code & function templates Not good for orthogonal concerns (mutually independent concerns) Cannot add functionality at arbitrary location transparently

15 Concluding Remarks AOP improved end-to-end performance (latency & throughput) of middleware Promising approach to automate specialization of middleware without refactoring middleware code Provides quantification of concerns - Crosscutting concerns is fully encapsulated in aspects AOP is not a replacement of OOP, but is used to enhance it Makes source code more readable/understandable by reducing tangling & scattering of code Future Work: Identify different points of generality in middleware to implement aspects Examine use of specialization for component middleware Use AspectC++ with Model Driven Development (MDD) Combine FOCUS & AOP approaches to automate the generation of the specialization directives Source code available from

16 Questions ??