Towards Aspect Oriented Middleware

1
Towards Aspect Oriented Middleware

• Charles Zhang and Hans-Arno Jacobsen
• Department of Electrical and Computer Engineering
  and
• Department of Computer Science
• University of Toronto

2
Outline

• Crosscutting concerns and aspect oriented
  programming (AOP).
• Applying AOP to the architecture of middleware
• Aspect orientation in middleware.
• Aspect mining.
• Aspect oriented re-factoring of middleware
  features.

3
Part One

• Why is there aspect oriented programming? I
  thought Object oriented programming could solve
  all my problems.
• What are aspect oriented programming languages?

4
Aspect Oriented Programming

• Definition To support the programmer in
  cleanly separating components and aspects from
  each other to abstract and compose them to
  produce the overall system
• Used when we have design goals conventional
  programming languages cannot capture.
• Capable of modularize pervasive properties of the
  system
• Complements conventional programming languages.

5
Crosscutting Problems The loop fusion example1

• Consider designing a specialized filter for an
  image processing system to produce a new image
  given two images.
• Decompose the complex filter into a set of
  primitive filters, such as AND, OR, XOR, etc.

6
Loop Fusion. A primitive filter

• Implementation of an OR filter
• Image OR ( Image image1, Image image2)
• Image result new Image(width,height)
• for(int i0iltwidthi)
• for(int j0jltheightj)
• resultij
• image1ij.OR(image2ij)
• return result

Takes two images
Create an temp image
Loop through both dimensions
Invoke OR operator on each pixel
7
Special filter design 1 easy to read, reason,
maintain and extend

• Image SpecialFilter(Image image1, Image image2)
• return AND(OR(image1, image2),
  XOR(OR(image1, image2),
• AND(image1,image2))

8
Problem With This Design

• Not memory efficient. 4 Intermediate images.

• Computationally expensive. 5 double loops.

9
Special Filter design two Efficiency

• We can fuse the loops together
• Image AlphaFilter(Image image1, Image image2)
• Image result new Image(width, height)
• for(int i0iltwidthi)
• for(int j0jltheightj)
• resultij
• (image1ij.OR(image2ij))
• .AND(((image1ij.OR(image2ij).
• XOR (image1ij.AND(image2ij)))))
• return result

10
Problem with this design

• Good in both memory management and reducing
  computational complexity
• 1 double loop, one image
• Bad in everything else
• Hard to read, reason and maintain. Error prone.

11
Special filter design threeTry to be modular
and efficient

• Let us fuse the XOR operation
• Image AlphaFilter(Image image1, Image image2)
• Image result new Image(width, height)
• for(int i0iltwidthi)
• for(int j0jltheightj)
• resultij
• (image1ij.OR(image2ij)).XOR
  
• (image1ij.AND(image2ij)))
• return AND(OR(image1,image2),result)

12
Problem with this design

• Improved reuse of existing modules. Improved
  memory management and computational efficiency by
  reducing number of intermediate steps.
• Logic is tangled.
• Neither as easy to manipulated as the 1st case,
  nor as efficient as the 2nd case. Both modularity
  and efficiency come into the design concern.

13
The design dilemma

• Design goal one Modularity
• Easy to reason, manipulate , reuse and maintain.
• Hiding information behind interface sometimes
  obstructs optimization.
• Design goal two Efficiency
• Reduce computational complexity. Direct control
  of resource.
• Hard to understand, change. Not modular.
• Concern crosscutting
• In general, whenever two properties being
  programmed must compose differently and yet be
  coordinated, we say that they cross-cut each
  other. 1

14
Goal of Aspect Oriented Programming

• Provide new methods and language features to
  address and to modularize both design concerns
• AOP exploits three artifacts
• A component language.
• An aspect language
• An aspect weaver

15
AOP solution to loop fusion problem

• Use primitive filters and write the special
  filter as in design one (Component program)
• Image SpecialFilter(Image image1, Image image2)
• return AND(OR(image1, image2),
  XOR(OR(image1, image2),AND(image1,image2))
• Use facilities provide by aspect oriented
  languages to intervene its execution. (Aspect
  program)
• FuseLoop(Image image1, Image image2)
• before SpecialFilter ()
• if(cflow(XOR) cflow(AND))
• //fuse the loops in OR and XOR
• //return result image
• Transformation of the component program
  (Weaving)
• byte code engineering, binary transformation,
  or runtime instrumentation.

16
Crosscutting problem Figure Editor, An AspectJ
example 2.
HistoryUpdating
17
More crosscutting about display.

• Collection of figure elements
• that move periodically
• must refresh the display as needed
• complex collection
• asynchronous events
• Other examples
• session liveness
• value caching

we will initially assume just a single display
18
Design Dilemma

• Design alternative one Place the display
  updating code inside the corresponding methods.
• Pro. Direct control of updating behaviour.
• Cons. Updating code scatters. Hard to add or
  modify a functionality.
• Design alternative two Visitors and observers.
• Pro. Less code bloating. Cleaner modularization.
• Cons. Requires binding of types. Still not
  modular.

19
a simple figure editor
class Line implements FigureElement private
Point p1, p2 Point getP1() return p1
Point getP2() return p2 void setP1(Point
p1) this.p1 p1 void setP2(Point p2)
this.p2 p2 void moveBy(int dx, int dy)
... class Point implements FigureElement
private int x 0, y 0 int getX() return
x int getY() return y void setX(int
x) this.x x void setY(int y) this.y
y void moveBy(int dx, int dy) ...
20
Solution in AspectJ
Construct represent a collection of points in the
execution of the base program

• aspect DisplayUpdating
• pointcut move()
• call(void FigureElement.moveBy(int, int))
• call(void Line.setP1(Point))
• call(void Line.setP2(Point))
• call(void Point.setX(int))
• call(void Point.setY(int))
• after() returning move()
• Display.update()
• before()move()
• History.save()
• Original modules are left intact.
• We add any new functionality as we desire.
• Dramatic coding reduction.

After all the functions return
Before all the functions execute
21
Aspect

• Definition 1
• Aspects tend not to be units of the systems
  functional decomposition, but rather to be
  properties that affect the performance or
  semantics of the components in systemic ways
• What could be an aspect?
• synchronization, scheduling, resource
  allocation, performance optimizations, failure
  handling, persistence, communication,
  replication, coordination,memory management, and
  real-time constraints

22
Visualizing Aspects

• Dynamic request handling in ORBacus
• red shows lines of code that handle dynamic
  request
• not in just one place
• not even in a small number of places

23
Overview of AOP

• Initially incepted by Gregor Kiczales,et al in 96
  and formally described in the ECOOP 97 paper.
• Current research focuses on the language and tool
  support.
• AspectJ3 Hyper/J4 Demeter/J 5 ,
  JAC6, and many others.
• Eclipse AJDT7, IBM Eclipse concern management
  environment (CME)
• Prism aspect analysis environment.
• Industry adoption
• Early adoption at Verizon wireless, Boeing.

24
Part Two

• Why is AOP attractive to the architecture of
  middleware?
• How to apply AOP to improve the design of
  middleware?

25
Middleware Platforms

• Middleware A set of services that facilitate
  developing distributed applications in a
  heterogeneous computing environment.
• Examples of Middleware
• CORBA, DCOM, Web Services, .NET, J2EE.

26
Driving Forces of Middleware Complexity
27
Evolution of Middleware

• CORBA

Core functionality
1996
1992
1997
1991
1998
2001
DSI Ref. Resolution GIOP
IDL DII C Mapping
BOA Object Model
Security IDL Ext.
Portable Interceptor
POA Java Mapping
Extrinsic functionality
2001
2000
2002
1996
Common Security (2.6)
Transaction Inter-Op OLE DCOM (2.0)
Messaging Minimum CORBA Real-time CORBA (2.5)
High performance Enabler(RFP)

• Other Platforms

Java platform J2SE / J2EE / J2ME /
RTJS .NET platform Standard Edition /
Embedded Edition
28
Concern crosscuttingA CORBA story

• A good decomposition of core functionality of
  middleware.

Application works with any CORBA with same
language with no change
Portable Skeleton / Stub
Normal method invocations
ORB specific Skeleton / Stub
Normal method invocations /Requests
Generic Request Message
Messaging Layer
Send and receive octet streams
Application works with any standard peer ORB
Transport Layer
Pluggable protocol. Transparently support IP,
ATM, TCAP, or any proprietary protocol
OS Network Layer
29
What is not well modularized?
Portable Skeleton / Stub
Dynamic Interface
Normal method invocations
Asynch call
ORB specific Skeleton / Stub
Local Invocation
Generic Request Message
Messaging Layer
Send and receive octet streams
Transport Layer
OS Network Layer
30
Why modularize them?

• Modularity is the key to high configurability.
• Reduce feature redundancy improves performance.
• Separation of concerns. Easy to maintain, easy to
  evolve.

31
Our Approach to aspect oriented middleware (AOM)

• Aspect Orientation Aspects of middleware are
  design concerns that are orthogonal to the core
  functionality of middleware.
• Aspect Mining Discover and quantify aspects in
  legacy middleware systems using a combination of
  types, lexical patterns, and language patterns.
  (On going Prism project.)
• Aspect Re-factoring Re-implement orthogonal
  design concerns in middleware core using AOP.

32
Aspect OrientationMiddleware Aspect Taxonomy
Aspect taxonomy helps to identify aspect concerns
of middleware design
33
Aspect Mining

• Aspects are non-localized and hence not easy to
  discover without algorithms and tools.
• Aspect mining aims at discovering and locating,
  in source code, the crosscutting properties in
  very large systems.
• Aspect can be quantified by degree of scattering.
  Percentage of classes make references to a set of
  signatures represent an aspect.
• Tools
• AMTEX. First tool performs aspect analysis on
  very large systems.
• Prism aspect mining environment for Eclipse. On
  going project, due October.

34
Aspect Mining CORBA Case Study

• Common Object Request Broker Architecture (CORBA)
  is a mature middleware platform.
• Open standard, convenient to analyze.
• Large code base.
• Availability of many implementations allows for
  cross comparison of mining results.
• Mining performed on three open source CORBA
  implementations in Java. All comply with CORBA
  2.0 and up.
• Size of the implementations

35
Aspect Mining Dynamic Programming Interface

• Definition Allow programs to dynamically compose
  or handle invocation request without prior
  knowledge of the interfaces.
• Fingerprints A set of java classes support this
  feature, including Any, Request, ServerRequest,
  DynamicImplementation, etc.
• Results
• Fingerprints are located across multiple layers
  of CORBA
• Degree of scattering
• JacOrb 23,
• ORBacus 26.56,
• OpenORB 23

36
Mining Results.
37
Analysis of Mining Results

• Discovered some internal ORB features such as
  DII, DSI and Interceptors cause considerable code
  scattering and logic crosscutting.
• The modularity of middleware is also hindered by
  common aspects such as logging, tracing,
  synchronization and pre/post condition checking
• In general, legacy middleware architectures
  inherently suffer from concern crosscutting.
  Aspect mining shows 50 of classes in all three
  implementations coordinate with a certain aspect.

38
AOP Based Re-factoring
39
Aspect Oriented Re-factoring

• Rationale Separation of aspects from middleware
  should preserve core functionality.
• Goal Quantify the benefit of using AOP in
  middleware architecture.
• Target Re-factoring performed on ORBacus, an
  open source CORBA platform from IONA.

40
Evaluation Metrics

• Standard measures to reflect architectural
  changes.
• Structural metrics
• Cyclomatic complexity
• Size
• Weight of class
• Coupling
• Behavioural metrics
• Response Time (Client/Server side
  marshall/unmarshalling).
• Numbers collected on PIII 1GHz Linux workstation

41
Overall Assessment

• The following table reflects the change of
  structural metrics over about 30 classes on four
  CORBA features.

• The following table shows the runtime performance
  (in ms)

42
Analysis of Re-factoring Results

• Re-factorization transparently support features
  composed in aspect programs.
• The performance of the core functionality is at
  least equivalent to the original implementation.
• Using AOP, middleware supports its core
  functionality with less complexity, lower
  coupling, smaller code size and simpler control
  flow.
• The architecture is more flexible and
  configurable as aspectized features can be
  configured in and out freely.

43
Future Work

• Prism project
• Provide matching capability of types, textual
  patterns, and language patterns.
• Designed for a unified language analysis
  platform. Enable aspect mining of other types of
  middleware systems in different languages.
• Aspect library implementations. Enable portable
  aspect functionality.
• Continue aspect re-factoring on other middleware
  systems, such J2EE, database, and more.
• Long term research goal Re-design middleware
  architecture using aspects.

44
Refences

• 1 Adapted from example in Aspect oriented
  programming, G. Kiczales, ACM Computing Surveys,
  1996
• 2 Borrowed from PARC aspectj presentations.
  www.eclipse.org/aspectj.
• 3 AspectJ, www.eclipse.org/aspectj
• 4 HyperJ, www.alphaworks.ibm.com/hyperj.
• 5 Demeter/J,
• 6 JAC, www.aopsys.com
• 7 AJDT, www.eclipse.org/ajdt

45
Thank You
46
Aspect Re-factoring Dynamic Invocation Interface

• Aspect Implementation Implementation classes are
  semantically separated from the original code.
• Some of the crosscutting points.
• Introduce dynamic request creation into ORB
  interface.
• Introduce dynamic invocation mechanism into the
  request sending process.
• Results

47
Mining Methodology

• What is aspect mining?
• In a stream of tokens, discover data and control
  flows that incur logic tangling.
• Currently, we characterize aspects by sets of
  types or textual patterns and denote them as
  characterization sets.
• We measure the percentage of classes that is
  crosscut by the characterization set.
• We call this the degree of scattering.
• Mining approaches
• Currently automatic discovery is not possible
  mining involves user intervention.
• Map well known aspects such as logging and
  synchronization to the types and expressions of
  target platform
• Discover orthogonal concerns of middleware.
  Define the characterization sets. And verify by
  computing the degree of scattering.
• Rank the scattering degree of all types to locate
  possible aspects.

48
Research Thesis

• Middleware systems implemented in traditional
  methods inherently suffer from concern
  crosscutting.
• The modularity of legacy middleware systems can
  be improved tremendously using AOP.
• It is time to re-think the architecture of
  middleware and incorporate AOP from ground-up.

49
More concerns cut across modules