Specialization of Middleware using Aspect Oriented Programming Project Presentation

1
Specialization of Middleware using Aspect
Oriented ProgrammingProject Presentation

Dimple Kaul CS 395 dimple.kaul_at_vanderbilt.edu Vand
erbilt University, Nashville, TN
2
Overview of Research Challenges

• Resolving the tension between
• Generality Middleware is designed to be
  independent of particular application
  requirements

• Specificity PLAs are driven by the functional
  QoS requirements for each product variant

Product-line Variant
Standards-based, General-purpose Middleware
Architecture
3
QoS Challenges in Middleware

• Redundant remoting functionality for
  collocated objects.
• Redundant (de)marshaling checks
• Byte order swapping (little endian, big endian)
• Redundant request creation and/or
  initialization
• Operation name
• Message size Same for a event
• Service context
• Overly Extensible
• Transport protocol (TCP, UDP or Shared memory)
• Concurrency model (single threaded, thread per
  connection, thread pool)
• Generality of deployment platform
• Heterogeneous/ Homogenous environment

4
Selecting specialization technique

• QoS challenges discussed can be best solved by
  using Aspect-oriented programming (AOP) tool
  because of following reasons
• It can change existing functionality without any
  re factoring of code.
• Functionality need not be known at design time
  of functionality.
• Implementations are easier to design,
  understand, and maintain.
• AOP promises higher productivity, improved
  quality, and better ability to implement newer
  features

5
What is Aspect Oriented Programming ?

• Separate crosscutting concerns
• Addresses each concern with minimal coupling
• Reduces/Prevents code clutter, tangling and
  scattering
• Allows programmer to express aspectual code which
  does not directly fit into component.
• Easy to add new functionality by creating new
  aspects
• Implements non-hierarchy conforming refinements
• More code reuse
• No worry of under/over design
• Run and Compile Time weaving

6
Aspect and Object Oriented Model
Functionality needs to be implemented in multiple
classes
For each requirement we can have separate aspect
7
Aspect Weaver
Using Joint points Aspect weaver combining
component and aspect code
(a) (b)
(a) New functionality unit added (red) in the
source program remains relatively contiguous in
the executable program. (b) Code that is part of
the separate aspect descriptions (red) in the
source program is woven together and spread about
in the executable program
Different Aspect Oriented Programming languages
are AspectC, AspectJ , JBOSS AOP
8
Important terminology of AOP

• Advice It is the code that is applied to, or
  cross cuts, existing model.
• e.g., before()? Before actual control flow is
  executed, advice body is executed
• after()? After a particular control
  flow is executed, advice body is executed
• around()?Advice body is executed
  instead of control flow
• Join point Points in the model where aspect can
  interfere.
• For example class, methods, structures etc.
• Pointcut It is set of Join points described by
  pointcut expression.
• Types of Pointcuts
• Execution() - picks out join points defining
  method execution (callee side)
• Call() - picks out join points defining method
  call (caller side)
• Get/Set() - picks out join points defining field
  access or modification
• Throws() - picks out join points defining where
  an exception is thrown out of a method
• Aspect The combination of the pointcut and the
  advice is termed an aspect.

9
Project Details

• In this project I am trying to handle Overly
  extensible challenge of middleware by selecting
  a particular Concurrency model.
• Reactor pattern of ACE middleware framework
  support several implementations
• Select Reactor
• -- single thread event demultiplexer
• Thread Pool Reactor
• -- multi thread event demultiplexer
• WFMO Reactor
• -- windows event demultiplexer

To work transparently across all the reactor
implementations, ACE uses Reactor_Impl abstract
base class which delegates to subclasses using
virtual method calls.
10
Project Details

• Reactor Specialization Using AOP
• Middleware reactor support multiple types
  implementations
• Only one type of reactor implementation is used
  in real sense

• Using crosscutting concerns of AspectC we can
  remove some indirections e.g., Virtual ness of
  method calls of Reactor_Impl base class can be
  eliminated and directly application specific
  reactor implementation method calls can be used
  instead.
• This way we can remove generality by removing
  indirections
• For the scope of project, specialization of two
  reactor implementations are done
• Select Reactor
• Thread Pool Reactor

11
Assumptions
Following things are assumed in the two
cases Select Reactor Specialization Application
will require only single threaded functionality
i.e., Select Reactor class. So, base class
Reactor_Impl will directly call Select_Reactor
method calls Thread Pool Reactor Specialization
Application will use only multi thread
functionality i.e., thread pool reactor class.
So, base class Reactor_Impl will directly call
TP_Reactor method calls.
12
Code snippets
On call of ACE_Reactor_Impl method in the
execution flow replacing it with
ACE_Select_Reactor_Impl method
Select Reactor and Thread Pool Reactor
Specialization aspect Single_Thread_Implementatio
n advice call (" ACE_Reactor_Implpurge_pend
ing_notifications(...)")around () //
printf("redirecting call of s ",
JoinPointsignature()) ((ACE_Select_Reactor_
Impl ) tjp-gttarget ())-gt
ACE_Select_Reactor_Implpurge_pending_notificatio
ns (tjp-gtarg lt 0 gt(),
tjp-gtarg lt 1 gt())

aspect Thread_Pool_Implementation
advice call (" ACE_Reactor_Implhandle_events(in
t)")around () ((ACE_TP_Reactor )
tjp-gttarget ())-gtACE_TP_Reactorhandle_events
(tjp-gt
arg lt 0 gt())

On call of ACE_Reactor_Impl method in the
execution flow replacing it with ACE_TP_Reactor
method
13
Testing Configurations

• To ensure
• Correct results
• Performance improvement
• Before and after using specialization tool
  following tests were conducted and corresponding
  result sets were gathered
• Latency test for single threaded application
• Roundtrip throughput test for single threaded
  application
• Latency test for the Thread-Pool concurrency
  model (multithreaded client and server)
• Roundtrip throughput test for the Thread-Pool
  concurrency model (multithreaded client and
  server)

14
Experiment setup and configuration

• System configuration
• Operating System Red Hat Linux 9 with kernel
  version 2.4.20-8
• Model Intel Pentium
• CPU Speed 2793.525 MHz
• Memory 1GB RAM
• Cache size 1024 KB
• Experiments
• Test run
• ACE_ROOT/TAO/performance-tests/Latency/Single_Thr
  ead
• ACE_ROOT/TAO/performance-tests/Latency/Thread_Poo
  l
• Number of test runs 10

15
Experimental Results
When ACE middleware framework used Select_Reactor
(single threaded implementation of Reactor) using
aspects
Latency of system decreased. Y-axis Latency
(µsecs) X-axis Number of tests conducted
Roundtrip throughput of system increased. Y-axis
Throughput (event/sec) X-axis Number of tests
conducted
16
Experimental Result (cont.)
When ACE middleware framework used TP_Reactor
(thread pool concurrency model having multithread
implementation of Reactor) using aspects
Roundtrip throughput of system increased. Y-axis
Throughput (event/sec) X-axis Number of tests
conducted
Latency of system decreased. Y-axis Latency
(µsecs) X-axis Number of tests conducted
17
Observations Problems faced

• Using AspectC 0.9.3 version ACE was not
  building
• Requires recompilation of source code and size of
  executable is increased
• AspectC not mature enough and is hard to
  implement
• No flexible way to describe the target components
• Does not work for middleware framework TAO/CIAO
• Does not transform macro-generated code and
  function templates
• Not good for orthogonal concerns( mutually
  independent concerns) i.e., Used at one place in
  original code and you are sure that it will not
  propagate to other part of system.
• Binding of aspect is independent of current
  development stage.
• You can add or modify behavior of code at any
  stage

18
Conclusion

• Aspect Oriented Programming (AspectC ) is an
  evolutionary step.
• Improves end-to-end performance (Latency and
  Throughput)
• AspectC provides us a better approach to change
  existing functionality without re factoring of
  middleware code.
• AOP is not a replacement of OOP but it is used to
  enhance it.
• Makes source code more readable/understandable by
  reducing tangling and scattering of code

• Future Goal
• Identifying new specialization points in
  middleware
• Implementing of aspects to other QoS challenges
  of middleware
• Comparing AOP with other upcoming new
  specialization tools

19
References
1 Scaling Step-Wise Refinement Don Batory,
Member, IEEE, Jacob Neal Sarvela, Student Member,
IEEE, and Axel Rauschmayer, Student Member,
IEEE 2 Combining Feature Oriented and Aspect
Oriented Programming to Support Software
Evolution Sven Apel, Thomas Leich, Marko Rosenm
uller, and Gunter Saake 3 Feature-Oriented
Customizer (FOCUS) for Distributed Real-time
Embedded Middleware Arvind Krishna 4
Feature-Oriented Programming and the AHEAD Tool
Suite Don Batory 5 Feature Oriented
Programming for Product-Lines Don
Batory 6 Generative Programming Czarnecki
K., Eisenecker U. W 7 Understanding Feature
Modularity in Feature Oriented Programming and
its Implications to Aspect Oriented
Programming Roberto E. Lopez-Herrejon 8 Model
driven Middleware Aniruddha Gokhale, Douglas C
Schmidt, Balachandran N, Jeff Gray, Nanbor Wang
20
Questions??