Building Customizable Middleware Using Aspect Oriented Programming

1
Building Customizable Middleware using Aspect
Oriented Programming
http//www.cs.wustl.edu/doc/RandD/PCES/facet/
Frank Hunleth, Ron Cytron, and Christopher
Gill Washington University in Saint
Louis Department of Computer Science
Center for Distributed Object Computing Department
of Computer Science Washington University
October 2001
2
Motivation

• Middleware designed to solve problems in many
  problem domains
• For any particular application, only a subset of
  features are used
• Enabling all features leads to code bloat and low
  performance
• Subsetting is application-specific and leaves
  ugly hooks in the code

Application
Middleware
3
Case study

• TAO RT CORBA subsetting
• Several month effort
• Many hooks added to core code
• Changes affected many components
• Many unrelated to RTCORBA (FT CORBA)
• Profiling on one platform indicated a null hook
  taking 1 processing time due to DLL calls

4
Using Aspects to Build Middleware

• Base middleware consists of only code common to
  any possible configuration
• Each feature is implemented using an aspect
• Feature code can be selected incrementally
• Currently through use of a configuration file
• Challenges
• Base code should consist of a subset of features
  common to all configurations
• Features should be selectable based on user
  requirements
• The number of features should be scalable
• Framework should exist to test every possible
  configuration of the middleware

5
Basic Event Channel Architecture

• Publish-Subscribe
• CORBA Event Service Notification Service TAO RT
  Event Service

Push
Push

• FACET
• Event Scheduling
• RMS, EDF, etc.
• Filtering
• Many options
• Buffering
• Correlation
• Policing
• Timeouts

Push
Event Channel
Push
Push
6
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

7
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

8
Feature Consistency

• 18 features ? 218 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
• AspectRegistry
• Instantiation of dependence graph
• Feature set validation
• Used to generate all event channel combinations
  for testing

AspectRegistry
Validation
Features
Base
Config Generation
Dependence Graph
Event Channel
9
Feature Consistency

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

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

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

11
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
• Valid if in-degree is greater than 0

12
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 detect combinations of aspects or code
  that cannot coexist
• Usually does not contain code
• Valid if in-degree is less than or equal to 1

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

• Inferred Features
• Used to represent features that are not present
  in the event channel configuration, but are
  required
• Valid if in-degree equals 0 (Never valid)

14
Example Adding the TTL Feature

• Determine minimum dependence set
• Structured event with a header
• Note Event payloads, filtering, etc. not
  pertinent to implementing the TTL
• Advantage Can think about TTL feature without
  having to deal with irrelevant features
• Write aspect to register the feature with the
  AspectRegistry

aspect CorbaTtlFeature extends AutoRegisterAspect
after(AspectRegistry ar) registry(ar)
ar.registerDependence(CorbaTtlFeature.class.getNam
e(), "edu.wustl.doc.even
ts.CorbaEventHeaderFeature")
15
Example Adding the TTL Feature

• Introduce the TTL field to the event header
• Added to the CORBA IDL specification
• Currently added using a set of Python scripts
• Very primitive
• Would like to specify IDL introductions closer to
  the Java aspects
• Write the code to check and decrement the TTL
  field

aspect CorbaTtlAspect boolean
update_ttl(Event event) event.header.ttl--
return event.header.ttl gt 0 void
around(EventCarrier ec) execution(void
EventChannelImpl.pushEvent(EventCarrier))
args(ec) if (update_ttl(ec.getEvent()))
proceed(ec)
16
Example Adding the TTL Feature

• Write a unit test to exercise the feature
• High level overview of test
• Configure an event channel with a supplier and
  consumer
• Create an event at the supplier
• Assign TTL of 0
• Send event, but expect it not to reach any
  consumers
• Create another event with TTL gt 0
• Send event and expect it to reach consumers with
  its TTL field decremented
• Use aspect to register unit test with the main
  event channel test suite
• Tests are automatically run after each build

17
Unrelated Feature Interactions

• Suppose that we have written a Performance
  Counter feature
• Adds event counters to event channel
• Only dependence is the base event channel
• Structured similar to TTL feature
• Advice at key locations to count significant
  events
• Unit test to verify that when events are sent
  that the appropriate counters are incremented
• What if an event channel is configured with both
  the TTL and Performance Counter features?
• Unit tests for both will be run as expected
• However, the Performance Counter tests do not set
  the TTL field of the events
• Dont even know about structured events
• Result All events sent in the Performance
  Counters tests will be dropped!

18
Solution Use Aspects

• Write an aspect to fix all unit tests that do
  not depend on the TTL feature
• Create TestUsesEventTtl interface
• Modify all unit test classes that depend on (know
  about) the TTL feature to implement this
  interface
• Create TestTtlAspect
• Adds advice after all constructions of
  EventHeaders in non-TTL enabled code to
  initialize the TTL

interface TestUsesEventTtl aspect
TestTtlAspect after () returning (EventHeader
header) call(EventHeader.new())
!this(TestUsesEventTtl) header.ttl 255

19
Procedure for Adding Features to FACET

• Decide what existing FACET features are required
• Configure FACET with only these features
• Register these dependences with the
  AspectRegistry class
• Write the code (using normal Java classes or
  aspects) to implement the feature
• 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 aspect to fix other
  FACET test cases
• Necessary if the feature introduces user visible
  changes that do not have reasonable defaults
• TTL feature

20
Current FACET Statistics

• Base
• 83 classes and aspects
• 10 actual implementation
• 13 AspectRegistry and feature support classes
• 5 AspectRegistry abstract aspects
• 55 CORBA generated
• Base most features enabled
• 239 classes and aspects
• 28 Base AspectRegistry and feature support
• 63 Implementation classes
• 48 Implementation aspects
• 100 Corba generated

21
Current FACET Dependence Graph

• 218 combinations if ignoring dependences
• 5052 valid configurations
• 10-30 seconds to build and test each one
• Combinations to test can be further reduced
• Only selectively testing debug aid features
  (e.g. logging)
• Adding mutexes to very unlikely combinations
  (e.g. having two types of event payloads
  simultaneously)
• Making concrete features, that are useless by
  themselves in practice, abstract

22
Concluding Remarks

• Ongoing and future work
• Quantify feature performance and code size impact
• How much overhead from aspects
• Incorporate more real-time features
• Automate nightly testing of feature combinations
• Open-source
• See http//www.cs.wustl.edu/doc/RandD/PCES/facet/

23
Discussion / Questions?
24
Encapsulated Parameter Pattern

• Probably wont have time?

I agree
25
Agenda

• Motivation
• Using Aspects to Build Middleware
• Managing Aspects
• Overview of FACET
• Example features and their construction
• Testing issues
• Current FACET statistics

Frank I would skip this slide. Probably not
enough time.