Dimitri Missoh
enthusiastic technologist and problem solver

December 20th, 2009

Aspect Oriented Programming with Object Teams/Java (Part I)

Aspect Oriented Programming (AOP)

The goal of Aspect Oriented Programming (AOP) is to improve the modularity in a software by offering the possibility to separate concerns. It provides another level of modularity in a piece of software.
A concern (also known as cross-cutting-concern) can be defined as a functionality or a coherent grouping of reusable functionalities that are (or can be) scattered over a software. Common examples of concerns are:

  • caching and
  • logging

In a classical object oriented architecture the programmer groups the functionalities of the software in modules, e.g. there would be a module that implements the persistence, another one to handle the login and so on.

In each of these modules you will definitely find recurrent pieces of code that are responsible for loggin or caching of important information/data.

Cross-Cutting Concern

The idea behind AOP is to extract and centralize this common functionalities (cross-cutting-concerns) in the so called aspects. The figure below visualize the notion of crossing-cutting-concern using the example of loggin.

Cross-Cutting Concern

Weaving strategies

The role of an AOP implementation is to provide a way to intercept method calls and define a set of rules to interact with the base code (the non aspect part). The term used to denote how the aspect code is “integrated” into the programming language is called weaving. The aspect code will be woven into the base code. Well-known weaving strategy are:

  • Compile-Time Weaving (CTW)
  • Load-Time Weaving (LTW)

Compile-Time weaving is the simplest one to implements, where the aspect compiler combines and compiles both the base and the aspect code to generate the woven classes.

Load-Time weaving operates at the byte code level. Every time the class loader is asked to return a given class, aspects are injected in the byte code (e.g. through the use of byte code instrumentation).

AspectJ and Equinox Aspects

One implementation of AOP for the Java programming language is AspectJ. The AspectJ Development Tools (AJDT) provides an excellent Eclipse platform based tool support for AOSD with AspectJ. From the need of supporting the use of AspectJ in OSGi, especially in Equinox (e.g. for Eclipse based applications), the Equinox Aspects project was born. For impatients, this quick start is a nice warm up to begin using Equinox Aspect.

I will not go deeper into Equinox Aspect, but rather give more details on Object Teams/J my favorite one.

Notes: For details on how AspectJ addresses weaving issue, please read this documentation.

Object Teams/Java

What is Object Teams/J?

As we saw in the previous session of this article, the aspect oriented paradigm has been introduced on the top of OOP to enhance the concept of modularity by providing a means to extract and centralize a concern. Object Teams goes the exta mile and provides a very interesting approach for the modularity and especially for the reuse of components. Although I’m only interested in OT/Equinox which is the integration of OT/J into the  Eclipse Equinox framework, I will give you in the next paragraph a short overview of the concepts behind OT.

OT defines two new construct for the programming language:

  • Team
  • Role

A Team is a grouping mechanism for collaborative units called Roles. I.e. a Team is aim to contains a set of Roles that interact with each other. A Role can not only interact with other Roles within a Team, but also can be bound to a base class. This bindings between a Role and a given base class can be defined using the relation ship called playedBy.

Two kind of method bindings have been defined:

  • callout binding
  • callin binding

Callout binding: Method calls done on a method of the Role will delegate this call to the method of the bounded base class. It works like a classic method inheritance in OOP. I.e. a callout binding just forward to the base.

Callin binding: A method invocation done by client code on a base class  will be intersected and redirected to the bounded Role-method. I.e. a calling binding intercept base methods. Callins are the aspect oriented part of Object Teams framework.

A Team, a Role, a Callin and a Callout are the most important concepts Object Teams is made up of. The figures below show how standard software pieces (in gray) interaction with a Team.

The principle of the Object Team framework.

The figure below shows a more detailed overview of how a OT projects interact with other software components.

A detailed overview of the OT interaction with other components.

In the example below, the rule ‘roleMethodY <- methodY‘ (in red) defined in the Team ‘MyTeam‘ is aim to intercept all method calls done on the method  ClassX.methodY(). If e.g. the method ClassZ.methodZ() try to call the method ClassX.methody() (see the sted (1) on the figure above), this call will be intercepted by the method MyTeam.Role2.roleMethodY() (see the step (2) and (3)). The method MyTeam.Role2.roleMethodY() is executed instead.

This is a typical example of a callin binding.

At the other hand, the developer would like to reuse some components (e.g. the logic implemented in the method ClassX.methodX()) in it Team implementation. E.g. a method implemented in the Role 1 calls the method Role2.roleMethodX() (see the step (a)). The developer knows that the logic he needs in the method Role2.roleMethodX() has already been implemented in the base class ClassX.methodX() and would like to reuse it. To solve this problem he just has to define the new rule ‘roleMethodX -> methodX‘ (in green), i.e. a callout binding (see the step (b)) that just forward the method invocation to the base method ClassX.methodX() (step (c)).

This is a typical example of a callout binding.

Here is quick update: I found a very nice blog entry describing the main concepts of OT in few words. It also explain how OT can be used on top of existing software modules to create new specializations (in form of Team grouping a set of Roles) to solve new problems without breaking the old architecture. The few diagrams on this blog show in a very nice way how Teams and Roles are aimed to enhance the modularity of a software. Have a look at: http://blog.objectteams.org/2010/07/object-teams-final-070/.

Let’s have a break

This should be enough for the theoretical part of this article, in one of my next post I will try to illustrate the power of the Object Teams framework with a very simple and comprehensive example based on a RCP project.

P.S.: The article Eclipse RCP for dummies shows have to build a simple RCP application in less than 2 minutes.