Building Customizable Middleware Using Aspect Oriented Programming

1
Building Customizable Middleware Using
Aspect-Oriented Programming
Frank HunlethApril 10, 2002Advisor Dr. Ron K.
Cytron
Center for Distributed Object Computing Department
of Computer Science Washington University
Sponsored by DARPA under contract F33615-00-C-1697
2
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

3
Traditional Middleware Development

• First release
• Clean and well decomposed design
• Core contains most functionality
• Subsequent releases
• Functionality added to core and features
• As core becomes bloated, refactor functionality
  to features
• Problems
• Only a subset of functionality used in most
  programs
• Preconceiving all extension points impossible
• Refactoring can be difficult and time consuming
• Hooks scattered through code

4
Traditional Middleware Development

• First release
• Clean and well decomposed design
• Core contains most functionality
• Subsequent releases
• Functionality added to core and features
• As core becomes bloated, refactor functionality
  to features
• Problems
• Only a subset of functionality used in most
  programs
• Preconceiving all extension points impossible
• Refactoring can be difficult and time consuming
• Hooks scattered through code
• Case study
• ACE and TAO

5
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

6
Advanced Separation of Concerns

• Concerns are logically related areas of a design
• Object Oriented Programming
• Class based decompositions
• Not all types of concerns can be decomposed
• Synchronization, memory management
• Crosscutting features and functionality
• Aspect Oriented Programming
• Encapsulation of concerns into Aspects

/ Id EventChannelTraceAspect.java,v 1.4
2002/02/27 165658 fhunleth Exp / package
edu.wustl.doc.facet.tracing import
edu.wustl.doc.facet. import org.apache.log4j.Ca
tegory import org.apache.log4j.NDC import
org.aspectj.lang.Signature / Enabling this
aspect weaves in tracing code throughout the
event channel. The tracing is done using
the Log4J logger. A good pattern for printing
out the trace messages is "-4r txmn"
/ aspect EventChannelTraceAspect /
Get the logging category / protected
static Category cat Category.getInstance
(EventChannelTraceAspect.class) /
Application classes. / pointcut
myClasses() within(edu.wustl.doc.facet..
) !within(edu.wustl.doc.facet.EventCha
nnelAdmin.) !within(edu.wustl.doc.face
t.EventComm.) !within(Test)
!within(edu.wustl.doc.facet.Upgradeable)
!within(EventChannelTraceAspect) /
The constructors in those classes. /
pointcut myConstructors() myClasses()
execution(new(..)) / The methods of
those classes. / pointcut myMethods()
myClasses() execution( (..)) protected
void enterMethod(Signature signature)
/ Update the indentation for tracing in this
thread. / NDC.push(" ") / Log
the message / cat.debug("Entering "
signature) protected void
exitMethod(Signature signature)
cat.debug("Exiting " signature)
NDC.pop() / Prints trace
messages before and after executing
constructors. / before ()
myConstructors() enterMethod(thisJoinPoi
ntStaticPart.getSignature()) after()
myConstructors() exitMethod(thisJoinPoin
tStaticPart.getSignature()) /
Prints trace messages before and after
executing methods. / before ()
myMethods() enterMethod(thisJoinPointSta
ticPart.getSignature()) after()
myMethods() exitMethod(thisJoinPointStat
icPart.getSignature())
Advice
aspect EventChannelTraceAspect /
Get the logging category / protected
static Category cat Category.getInstance
(EventChannelTraceAspect.class) /
Application classes. / pointcut
myClasses() within(edu.wustl.doc.facet..
) !within(edu.wustl.doc.facet.EventCha
nnelAdmin.)
Aspect
Joinpoints
Code
7
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

8
Novel Compositional Approach Using AOP

• Develop a simple base
• Contains minimal code common to all
  configurations
• Provides consistent structural framework
• Stable
• Add functionality with features
• One feature to one concern
• Aspects used to augment base and other features
• User selectable
• Results
• Very little code bloat or performance degradation
• Flexibility without need for strategizing base
  code
• Simpler to read code since only one concern is
  viewed at a time

9
FACET

• Framework for Aspect Composition for an EvenT
  channel
• Modeled after features from the TAO Real-time
  Event Service

Push
Push

• Features
• Payload choices
• Filtering
• Correlation
• Pull semantics
• Federation
• Policing
• Timeouts
• Event Scheduling
• RMS, EDF, etc.

Push
Event Channel
Push
Push
Supplier
10
The Base

• CORBA Interrupt Service
• Contains
• IDL specifications for simple push consumers
  and suppliers
• No event data is passed
• push() method call takes no arguments
• Event channel forwards all events to all
  consumers
• No filtering
• Tension
• Additive nature of aspects favors minimal base
• Practical debugging favors more functional base

11
Features

• Fine grained decomposition of Event Channel
• Introduction based features
• Event payload type
• CORBA Any
• Structured event
• Event header for the structured event
• Type field
• Advice based features
• Event channel dispatch options
• Filtering and event correlation
• Mixed introduction/advice features
• Time to live feature
• Performance statistics

12
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

13
Feature Consistency

• 21 features ? 221 combinations
• Not all combinations of features create viable
  event channels
• Only one event type allowed at a time (CORBA
  Any or structured event)
• TTL feature depends on the structured event
  header feature
• Should notify event channel user of
  misconfiguration
• FeatureRegistry
• Instantiation of dependence graph
• Feature set validation
• Used to generate all event channel combinations
  for testing

FeatureRegistry
Validation
Features
Base
Config Generation
Dependence Graph
Event Channel
14
Feature Consistency

• All features register at initialization with the
  FeatureRegistry
• Validation occurs at compile-time and run-time
• Many invalid combinations cause compiler errors
• Silent errors
• Advice not applied due to missing joinpoints
• Unreachable code

FeatureRegistry
Validation
Features
Base
Config Generation
Dependence Graph
Event Channel
15
Simplified FACET Dependence Graph
Base
Performance Counters
Event Type Mutex
Structured Event
CORBA Any Event
Event Header
Octet Seq. Payload
TTL

• Concrete Features
• Provide complete implementations of features
• Most FACET features fall into this category
• Valid if dependences met

16
Simplified FACET Dependence Graph
Base
Performance Counters
Event Type Mutex
Structured Event
CORBA Any Event
Event Header
Octet Seq. Payload
TTL

• Abstract Features
• Provides common set of introductions, advice, or
  tests used by sub-dependences
• Feature is not complete by itself
• Valid if in-degree is greater than 0

17
Simplified FACET Dependence Graph
Base
Performance Counters
Event Type Mutex
Structured Event
CORBA Any Event
Event Header
Octet Seq. Payload
TTL

• Mutual Exclusion Features
• Used to define combinations of features that
  cannot coexist
• Usually does not contain code
• Valid if in-degree is equal to 1

18
Dependence Relationships

• Normal dependence
• Signifies that one feature requires another to
  work
• Concrete ? Abstract Completes the abstract
  feature
• Any ? Mutex Acquires the mutex feature
• Event Header ? Event TTL ? Event Header
• Contains dependence
• Signifies that one feature contains another
  feature
• Similar to has-a relationship in OOP
• Does not complete abstract features or acquire
  mutexes
• Event Set ? Event Event Pull ? Event
• Circular dependence relationships
• Refactor to remove cycle

19
FACET Dependence Graph

• 4,596 valid configurations
• To date, 9,192 valid configurations
• ant featuregraph

20
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

21
Unit Tests

• jUnit test framework used
• Every feature provides set of unit tests
• Unit tests for every enabled feature run as part
  of the build process
• All combinations tested periodically
• FeatureRegistry enumerates valid combinations
• Build and test take 20-40 seconds per combination
• Full coverage in a few days with one computer
• Embarrassingly parallel
• Important configurations and random sampling
  effective in practice
• Footprint and performance data can be captured

22
Unit Test and Feature Interaction

• Unit test written in isolation
• Use minimum feature set required for tests
• No knowledge needed of future features
• What happens when future features change the
  behavior of the event channel?
• Case study TTL feature
• Adds Time-to-Live field to events
• Drops events when field reaches zero
• Default value is zero (mandated by CORBA)
• All previously written tests fail!

23
Upgraders

• Unit tests built for one feature may break when
  combined with another
• New parameters
• New registration method
• Solution is to create an Upgrader aspect
• Upgrades code that was not written for a feature
• Code must implement Upgradeable interface
• Used to upgrade application code too

aspect CorbaTtlUpgrader pointcut
upgradeLocations() this(Upgradeable)
!this(CorbaTtlFeature) after () returning
(EventHeader header) call(EventHeader.ne
w()) upgradeLocations()
header.ttl 255
24
Adding New Features to FACET

• Decide what existing FACET features are required
• Configure FACET with only these features
• Register these dependences with the
  FeatureRegistry
• Write the code to implement the feature
• Normal Java classes and aspects
• Write a jUnit test case to validate the feature
• Be sure to only use FACET features that are
  required
• May want to write test cases first
• If necessary, write an Upgrader aspect to fix
  other FACET test cases
• Test with a full featured configuration

25
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

26
Experimental Setup

• Footprint
• Class file sizes
• Simple sum of class file sizes
• Constant pool
• Byte codes
• Other meta data
• Jopt used to remove debug and ajc metadata
• Object files
• gcj Java to native code compiler
• Sum of text and initialized data sections
• Performance
• Linux 2.4 kernel running on a dual 933Mhz Pentium
• Sun JDK 1.3.1_02 / JacORB 1.3.30

27
Common Configurations

• TAO-users poll
• 9 interesting configurations identified
• Base (Config 0)
• COS Event Service with/without tracing (Config
  1,2)
• Any payload/TTL/Event Sets (Config 3)
• OctetSeq payload/Event type filtering (Config 4)
• Any payload/TTL/Event Sets/Filtering/Pull (Config
  5)
• OctetSeq payload/Timestamp/Correlation (Config 6)
• Almost all features except tracing (Config 7)
• Config 7 with tracing (Config 8)
• Configuration 6 used in Boeing Bold Stroke

28
Library Footprint
OctetSeq payload/Correlation
Base Only
29
Additional Code From External Libraries
30
Footprint Results
Key A Simple event filtering B Event
correlation C Event Set support D Event Pull
support E Octet sequence payload F Any
payload G String payload H CORBA Any events I
Calculated Event header J Event type K
Timestamp L Time to live field and
processing M Profiling support N Event
statistics counters
31
Throughput for Common Configurations
32
Feature Performance Results
Key A Simple event filtering B Event
correlation C Event Set support D Event Pull
support E Octet sequence payload F Any
payload G String payload H CORBA Any events I
Calculated Event header J Event type K
Timestamp L Time to live field and
processing M Profiling support N Event
statistics counters
33
Evaluating the Alternatives

• AOP versus using hooks
• Tracing feature implemented using hooks
• Automated hook insertion using AOP
• Intermediate Java code verified
• Useful if dynamic tracing ability needed
• Large gain if inter-DLL calls can be avoided

34
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

35
Encapsulated Parameter Pattern

• Problem
• How to extend existing method calls to pass new
  parameters needed for features
• Adding parameters to method signatures doesnt
  work
• Using cflow not always possible
• Solution
• Encapsulate parameters in a class and pass the
  class

36
Template Advice Pattern

• Problem
• Advice location and pointcut used many places
• Actual advice varies and is used in many
  locations
• Solution
• Define advice and pointcut in abstract aspect
• Add skeleton method for sub-aspects to override
• Similar in structure to the Template Method
  pattern
• Different contexts and dynamics

37
Interface Tag Pattern

• Problem
• Advice needs to be applied to arbitrary classes
• Specifying pointcut centrally does not make sense
• Solution
• Create an empty interface to tag classes that
  need to receive advice
• Apply advice to all classes that implement the tag

38
Overview

• Motivation
• Aspect Oriented Programming
• Approach and implementation in FACET
• Feature Management
• Testing
• Experimental Results
• AOP Design Patterns
• Conclusions and Future Work

39
Contributions

• Highly customizable CORBA event channel
• Novel and practical approach to building
  composable middleware
• Reusable feature management framework
• Several design patterns for developing middleware
  using AOP
• Test and verification framework
• Footprint and performance results supporting the
  use of AOP techniques

40
Future Work

• Add feature support for the RTSJ and real-time
  event distribution
• Investigate AOP techniques to extract CORBA as a
  FACET feature
• Non-CORBA environments
• Java RMI support
• May lead to ability to create distribution
  aspects
• AOP libraries
• Instead of creating 9,192 libraries, create 1
• Requires incremental compilation and specialized
  selection of aspects to actually use
• Transfer AOP techniques from Java to C

41
Thanks

• Advisor
• Dr. Ron K. Cytron
• Thesis Committee
• Dr. Chris D. Gill
• Dr. Doug Niehaus
• Dr. Ken J. Goldman
• DOC Group

42
Questions
43
Aspect Oriented Programming

• Joinpoint A well-defined point in a program
• Pointcut An expression containing joinpoints
• Advice Code that is applied at a pointcut
• Introduction Methods or variables that are
  added to existing classes and interfaces
• Weaving the process of applying advice and
  introduction
• Implementations
• AspectJ
• AspectC
• AspectC
• http//aosd.net/tools.html

44
AspectJ Example
aspect EventChannelTraceAspect protected
static Category cat Category.getInstance
(EventChannelTraceAspect.class) pointcut
classesToTrace() within(edu.wustl.doc.fa
cet..) !within(EventChannelTraceAspect
) pointcut methodsToTrace()
classesToTrace() execution( (..))
protected void enterMethod(Signature signature)
cat.debug("Entering " signature)
protected void exitMethod(Signature
signature) cat.debug("Exiting "
signature) before ()
methodsToTrace() enterMethod(thisJoinPoi
ntStaticPart.getSignature()) after ()
methodsToTrace() exitMethod(thisJoinPoin
tStaticPart.getSignature())
Member variable
Joinpoints
Methods
Advice
45
Traditional Middleware Development

• First release
• Clean and well decomposed design
• Core contains most functionality
• Some pluggable features
• Subsequent releases
• Functionality added to core and features
• As core becomes bloated, refactor functionality
  to features
• Problems
• Not all functionality can be preconceived
• Refactoring can be difficult and time consuming
• Case Studies
• ACE and TAO