Middleware Specialization using Aspect-Oriented Programming

1
Middleware Specialization using Aspect-Oriented
Programming
Dimple Kaul, Aniruddha Gokhale dimple.kaul,a.gokh
ale_at_vanderbilt.edu Institute for Software
Integrated Systems, Dept. of Electrical Eng
Computer Sc Vanderbilt University, Nashville,
Tennessee
March 10th 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

• Product line architectures 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
3
Factors Affecting QoS in Middleware

• Remoting functionality
• for collocated objects
• Bypasses I/O subsystem
• Marshaling/demarshaling
• checks
• byte order Little endian, big endian
• Overly Extensible
• Transport protocol (TCP, UDP,
• or Shared memory)
• Concurrency model
• (single-threaded, thread pool,
• thread-per-connection)
• Request creation /or initialization
• Operation name
• Message size
• Service context
• Generality of deployment
• platform
• Heterogeneous/homogenous

Same for an event
Need to tailor optimize standards middleware
for PLAs while also supporting standards
compliance, portability, flexibility
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

• But have shortcomings
• Manual Error prone
• High Memory consumption
• Performance overhead

Aspect Oriented Programming languages include
AspectC, AspectJ, JBOSS AOP
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

Requirement is dependent on multiple classes

• 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

Each requirement can have separate aspect
... In programs P, whenever condition C
arises, perform action A
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

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
Reactor Specialization Using AOP

• 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

Product Line1
Product Line 2
Product Line 3

• Applied specialization of two reactor
  implementations
• Select Reactor
• Thread Pool Reactor

Middleware supports multiple types of Reactor
implementations but a particular product variant
may need only one implementation
9
Reactor Specialization Using AOP
advice Specifies what code should run

• 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_notificat
ions(...)")around () ((ACE_Select_Reacto
r_Impl ) tjp-gttarget ())-gt ACE_Select_Reactor_
Impl purge_pending_notifications
(tjp-gtarg lt 0 gt(), tjp-gtarg lt 1 gt())

ThreadPool Reactor Specialization aspect
Thread_Pool_Implementation advice call ("
ACE_Reactor_Impl handle_events(int)")
around () ((ACE_TP_Reactor ) tjp-gttarget
())-gt ACE_TP_Reactorhandle_events
(tjp-gtarg lt 0 gt())
around advice body is executed instead of
control flow
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
10
Experiment Setup Configuration

• System configuration
• OS Version Red Hat Linux 9 with kernel version
  2.4.20-8
• 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

http//www.cs.wustl.edu/schmidt/ACE.html
11
Experimental Results (1/2)

• ACE middleware framework configured with
  ACE_Select_Reactor (single-threaded
  implementation of Reactor) using aspects

Average latency of system improved by 3
Average roundtrip throughput of system improved
by 2
of iterations 100,000
Assumption Application only requires
single-threaded functionality Note Rest of the
code path is not changed
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

Average latency of system improved by 4
Average roundtrip throughput of system improved
by 3
of iterations 150,000
Assumption Application only requires
multi-threaded functionality Note Rest of the
code path is not changed
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

//File Reactor.h //_at__at_ REACTOR_SPL_INCLUDE_HOOK cl
ass Reactor public virtual int
run_reactor_event_loop (REACTOR_EVENT_HOOK 0)
// Other public methods .... private
ACE_Reactor_Impl reactor_impl_ // ......
Customization engine transforms annotations
//File Reactor.h //_at__at_ 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 //
......
Normal C compiler is used to compile code
Specialized Middleware
General Middleware with hooks
14
Observations

• Pros
• Performance improved with increase in number of
  specializations
• AspectC is like AspectJ in syntax semantics,
  so its 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

• 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
• Doesnt transform macro-generated code function
  templates
• Not good for orthogonal concerns (mutually
  independent concerns)
• Cannot add functionality at arbitrary location
  transparently

We expect an additive increase in performance
when we implement this specialization for other
QoS challenges
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 www.dre.vanderbilt.edu/
dkaul/aspect/
16
Questions??