Object-oriented design focuses on the clean separation of concerns within a system. A concern is a concept, objective, or functional area that is of interest to the system. For example, a core concern of a stock-control system would be tracking stock items held at the warehouse.

Object-oriented languages provide the constructs necessary to localize the different concerns of a system into discrete modules. This is a fundamental approach to good software design and was practiced long before OOP came on the scene. Procedural languages put the rudimentary building blocks in place to enable the functional decomposition of concerns into modules. OOP built on the structures offered by procedural languages for modularization, introducing concepts such as information hiding and abstraction to facilitate the separation of concerns within a software system.

The problem with concerns is that they don’t all fit neatly into little boxes. Some concerns freely cross module boundaries and intersect with other concerns. These are known as crosscutting concerns and are generally associated with system-level concerns such as logging, threading, security, transactions, and performance. Such concerns are orthogonal to the core business concerns.

Crosscutting concerns are a dilemma for the software engineer, as OOP languages fail to offer a convenient mechanism for protecting the code base from the unwanted complexity they introduce into even the cleanest of software designs.

Crosscutting concerns are damaging to the design of software systems. They introduce the two unwanted side effects of code tangling and code scattering into the software architecture. Code tangling and scattering adversely affect the readability and maintainability of the application:

The impacts of crosscutting concerns on enterprise software are detrimental to the objectives of producing applications that are both readable and maintainable. Software that is hard to understand is difficult to maintain; code that is difficult to maintain cannot undergo rapid change in response to the evolving requirements of the business.

Fortunately, OOP is not completely defenseless against the ravages of crosscutting concerns, and various strategies are available to keep their impact to a minimum. These strategies essentially include the use of frameworks, design patterns, domain-specific languages, and mix-in classes. We briefly cover each of these techniques before examining how AOP addresses the issue.

The next sections look at the main techniques available for managing crosscutting concerns within the confines of a single paradigm OOP language such as Java.

OOP adds numerous new terms to the software engineer’s vocabulary, such as inheritance, composition, overloading, overriding, and everyone’s favorite—polymorphism. Learning the practices of OOP requires familiarity with these alien concepts.

Like OOP, AOP also comes complete with its own nomenclature, requiring our vocabulary to expand once again to encompass the paradigm’s concepts of crosscutting concerns, join points, pointcuts, advice, aspects, and weaving.

Here is an explanation of the AOP terminology:

AOP is therefore a process of weaving aspects that define crosscutting concerns into an application implemented in a conventional language that defines the core concerns. The result of the weaving process is a combination of concern types that make up the final system.

Classes and aspects are independent of one another, with only the pointcut declaration serving to bind the two paradigms. Classes are therefore unaware of the presence of aspects, and this is an important AOP concept.

This relationship between aspects and classes is very well described in an excellent early paper on AOP, Aspect-Oriented Programming: A Critical Analysis of a New Programming Paradigm [Highley, 1999]. The paper’s authors illustrate the relationship between OOP classes and AOP aspects by describing a mythical world inhabited by hunchbacks and dragons.

Taken from the paper, the hunchbacks of the mythical world all worked in houses with glass ceilings. Dragons flew around the skies, observing the behavior of the hunchbacks in the houses below. The hunchbacks couldn’t look up and so were unaware of the existence of the dragons.

The hunchbacks communicated with hunchbacks in other houses by sending each other mail. The mail they received from other hunchbacks helped direct the work they completed for the day. The dragons, being inquisitive creatures, kept a close eye on the hunchbacks, including reading the hunchbacks’ mail—however, the dragons never stole or interfered with the mail.

At a given point, the dragons would suddenly leap into action. They might, for example, paint one of the houses red. The hunchbacks would notice their house had magically changed color, but they wouldn’t do anything about it. They would continue with their everyday tasks, still oblivious to the existence of the dragons.

This allegory perfectly captures the relationship between classes and aspects. From the story, the classes relate to the hunchbacks while the flying dragons represent aspects. An OOP application is self-contained, but aspects allow the augmentation of the application’s behavior without the need to change the underlying static object model. Aspects therefore offer the ability to inject new behavior into an existing system dynamically and transparently.

The task of mixing the two worlds of OOP and AOP is achieved using a weaver.

The process of weaving is critical to AOP. As the AOP paradigm has evolved, various approaches to the process of weaving have emerged. The following lists the different methods for injecting advice into a Java application:

Load-time and runtime weaving methods have the advantage of being highly dynamic, enabling on-the-fly changes to a running system. On the downside, such changes can adversely affect system stability and performance. In contrast, compile-time weaving offers superior performance, but requires the rebuilding and deployment of the application in order to effect a change.

Having set the scene, it is now time to go over an AOP example to illustrate how the various AOP concepts are applied. We first look at an example of AOP using AspectJ, an AOP language implementation, and then compare it to AspectWerkz, a framework for adding aspects to Java applications.

The Eclipse platform is a generic development environment that offers a powerful collection of Java development tools (JDT), including a Java source editor, compiler, and debugger.

AspectJ builds on the services of the JDT to provide the AspectJ Development Tool (AJDT), a fully featured Eclipse plug-in that brings the capabilities of the Eclipse platform to the AspectJ language, including content assist on keywords, aspect browsing, compilation error tracing, and the debugging of aspects.

Despite its links with Eclipse, AspectJ is not bound to the Eclipse platform. The primary focus of the project is the AspectJ compiler, which is available as a standalone executable. As a standalone release, independent of the AJDT, AspectJ supports the compilation and execution of applications. A structure browser is also available for interrogating AOP constructs within the code.

AspectJ also integrates with other popular development environments, with plug-ins available for JBuilder, NetBeans, and Emacs. Refer to the AspectJ site for information on where to obtain these and other plug-ins.

AspectJ supports compile-time weaving, with version 1.1.2 offering limited support for load-time weaving.

The AspectJ compiler builds on the capabilities of Eclipse’s Java compiler, thereby firmly tying the language to the open source community and cutting its initial ties with javac. The Eclipse compiler is highly sophisticated and offers capabilities such as incremental compilation. By using the Eclipse compiler as its base, AspectJ leverages these capabilities for its own builds. Classes produced by the AspectJ compiler run on any Java-compatible platform.

To understand how some of the fundamental concepts of AOP are applied, let’s look at an example built using AspectJ. The example covers the main concepts of AOP and introduces the new language constructs AspectJ adds to the Java language to support AOP.

The code for the example adds aspects to an imaginary stock-control system. Stock items are contained within a central warehouse, and the stock-control system is responsible for managing all stock going into the warehouse. A single class encapsulates warehouse functionality. Listing 11-1 shows the implementation of the Warehouse class.

package stock;

import java.util.ArrayList;

/**
 * Warehouse class for storing stock items.
 */
public class Warehouse {

  private ArrayList stockItems;

  public Warehouse() {
    stockItems = new ArrayList();
  }
  /**
   * Add a new stock item
   */
  public void add(String stockItem) {
    stockItems.add(stockItem);
  }

  /**
   * Return the number of items in stock
   */
  public int itemsInStock() {
    return stockItems.size();
  }
}

The warehouse is nothing more than a wrapper around an ArrayList. However, the intention of the code is to demonstrate the concepts of AOP, not to build a fully featured stock-control system.

Our rudimentary stock-control system adds a number of stock items to the warehouse. Listing 11-2 shows the code for the stock-control example.

package stock;

/**
 * Adds stock items to the warehouse
 */
public class StockControl {

  public void processStockItems() {

    //  Create the warehouse
    //
    Warehouse warehouse = new Warehouse();

    // Add some stock
    //
    warehouse.add("Washing Machine");
    warehouse.add("Microwave Oven");
    warehouse.add("Television");
  }

  public static void main(String[] args) {
    StockControl stockCtrl = new StockControl();
    stockCtrl.processStockItems();
  }
}

The example application is very simple, but it is easy to imagine a production version on a much grander scale. The concept of encapsulating the warehouse functionality into a component accessed via a common interface from all parts of the system is a design in keeping with object-oriented architecture.

To illustrate how AOP weaves in functionality, we introduce an auditing (or logging) concern into the system. The following use case defines the new auditing requirements:

To incorporate the new requirements into the system using AOP, the first task is to specify the join points in the program where the auditing concern crosscuts the main concern. Achieving this task requires the declaration of a pointcut designator.

A pointcut designator is a special AOP language construct that specifies join point collections and precisely defines where a crosscutting concern intersects the main concern. AspectJ supports the declaration of pointcuts at a number of different locations in a program’s execution:

Complying with the auditing requirements requires the declaration of a pointcut occurring at the point of the call to the add() method on the Warehouse class. We need to weave in the auditing advice ahead of the add() method’s invocation and upon returning from the call.

Listing 11-3 shows the code for the aspect that specifies the pointcut declaration and the advice for weaving into the system.

package stock;

import org.aspectj.lang.reflect.SourceLocation;

/**
 * Aspect to add auditing to the stock control system.
 */
public aspect AuditingAspect {

  // Pointcut declaration
  //
  pointcut auditStockItem() : call(* Warehouse.add(..));

  // Advice to execute before call
  //
  before() : auditStockItem() {
    System.out.println("<--Audit log entry start-->");

    // Log the name of the calling class
    //
    SourceLocation sl = thisJoinPoint.getSourceLocation();
    Class myClass = (Class)sl.getWithinType();
    System.out.println("	Caller: " + myClass.toString());

    // Log the stock item description
    //
    Object[] args = thisJoinPoint.getArgs();
    for(int i=0; i < args.length; ++i) {
      System.out.println("	Adding item: " + args[i]);
    }
  }

  // Advice to execute after call
  //
  after() : auditStockItem() {
    Warehouse warehouse;
    warehouse = (Warehouse) thisJoinPoint.getTarget();
    System.out.println("	Items in stock: " +
                        warehouse.itemsInStock());
    System.out.println("<--Audit log entry end-->");
  }
}

Examining the code in Listing 11-3 reveals a number of syntactic differences from standard Java, with the AOP keywords shown in bold text. The AspectJ keyword aspect specifies that we are defining an aspect and not a Java class. AspectJ uses aspects as a unit of modularization for crosscutting concerns. Aspects are similar to classes in that they have a type and can extend classes and other aspects. The main difference between the two constructs is that aspects cannot be instantiated with the new operator. They are also not directly interchangeable with classes.

The keyword pointcut declares the pointcut designator for the auditing advice and assigns the pointcut the name of auditStockItem(). Here is the full declaration of the pointcut:

pointcut auditStockItem() : call(* Warehouse.add(..));

The syntax following the pointcut name is of greatest interest because this captures the join points for the auditing concern. It is defined as call(* Warehouse.add(..), where call specifies the join point as the point at which the method is invoked. The remainder of the pointcut designator specifies the method signature for matching the join point at runtime. From the example, a match will be found for all add() methods on instances of the Warehouse class, regardless of access, return type, or arguments. AspectJ provides a rich syntax for defining join points, enabling the definition of sophisticated matches that go well beyond the simple example shown.

Having identified the join points in the program, the next step is to provide the auditing advice AspectJ will weave into the main concern. AspectJ has three options for associating advice with a join point: before(), after(), or around() the join point.

Our auditing advice has to both precede and follow the call to the Warehouse instance. The AspectJ syntax of before() and after() details precisely where the advice is to be injected once the join point is reached. This syntax gives the following method signatures for the auditing advice:

before() : auditStockItem() {
  ...

after() : auditStockItem() {
  ...

Examining the code for the before and after advice highlights the use of the thisJoinPoint object, which provides a context for the join point and makes information relating to the join point available to the advice. The example uses this information to log the name of the calling class and the arguments to the Warehouse.add() method, and to invoke the itemsInStock() method on the Warehouse instance.

The code for the example was compiled and run on the Eclipse platform using the Eclipse AJDT plug-in. The use of an aspect-aware development environment offers significant benefits over a plain code editor and build script. In addition to syntax coloring of keywords and content-assist on AspectJ types, aspect-aware environments, such as AJDT for Eclipse, provide a visual cue to where join points occur within the application. This is an invaluable aid for determining the impact of a pointcut declaration upon the code of the core concerns.

Figure 11-1 depicts this feature of the AJDT, which shows the code from the example open as a project on the Eclipse platform.

Figure 11-1. The Eclipse platform with an AspectJ project open.

The upper right pane shows the code for the StockControl class open in an aspect-aware editor. Marks on the left border of the editor denote where the join points of the AuditingAspect aspect crosscut the StockControl concerns. The content of the outline view, seen in the lower left pane, displays a hierarchical view of the location of the aspect’s injected advice. The lower right pane contains the console view, which shows the results of executing the program.

The example contains only a single class and aspect. However, in a larger system with thousands of files, the pointcut declaration is just as easily applied across all classes within the system. This ability to inject functionality directly into a large system and with a high degree of precision makes AOP an ideal candidate for a rapid development language. Moreover, the dynamic nature of the language makes it an ideal prototyping tool because new behavior is easily added or removed as system functionality is explored.

AspectJ was the first release of an AOP language and still stands out as the most comprehensive AOP implementation available, offering unrivaled tool support in the form of the AJDT for Eclipse. Since its emergence from the research labs of Xerox PARC, a host of alternative AOP implementations has joined AspectJ. These newcomers to the AOP paradigm take a different approach to AspectJ. Instead of a new language, they provide a framework for defining aspects. The next section discusses this approach.

The number of open source AOP frameworks available is growing steadily as AOP continues to gain interest among the Java community. Table 11-1 lists a selection of the AOP frameworks available as open source.

To contrast AspectJ against a framework AOP implementation, we look at the approach to defining aspects taken by AspectWerkz.

One of the first approaches of many of the AOP frameworks was to declare pointcut designators and the location of advice methods using XML definition files. Listing 11-5 shows a sample of an AspectWerkz definition file that turns the plain AuditingAspect Java class into an aspect.

<aspectwerkz>
  <system id="stockcontrol">
    <package name="stock">

      <!-- Define the class implementing the aspect -->
      <aspect class="stock.AuditingAspect"
              deployment-model="perInstance">

         <!-- Named pointcut -->
         <pointcut name="auditStockItem"
                   expression="call(* Warehouse.add(..))"/>

         <!-- Bind aspect before method to pointcut -->
         <advice name="beforeAddStockItem"
                 type="before"
                 bind-to="auditStockItem"/>

         <!-- Bind aspect after method to pointcut -->
         <advice name="afterAddStockItem"
                 type="after"
                 bind-to="auditStockItem"/>

      </aspect>
    </package>
  </system>
</aspectwerkz>

Comparing the aspect definition in the XML file against the example from AspectJ reveals many similarities. Most notable is the syntax for the pointcut declaration. For example, here is the declaration for the pointcut in AspectJ:

pointcut auditStockItem() : call(* Warehouse.add(..));

Compare this to the corresponding declaration in the AspectWerkz configuration:

<pointcut name="auditStockItem"
          expression="call(* Warehouse.add(..))"/>

Later versions of AspectWerkz offer an alternative mechanism for specifying aspects using metadata annotations. This method moves AspectWerkz closer to the AspectJ model by embedding AOP constructs as annotations within the language. The advantage of embedded annotations over an external XML file is that all code related to the aspect resides within a single file.

Listing 11-6 shows the AuditingAspect class but this time adorned with AspectWerkz annotations.

package stock;

import org.codehaus.aspectwerkz.joinpoint.JoinPoint;

/**
 * @Aspect perInstance
 */
public class AuditingAspect {

  /**
   * @Before call(* Warehouse.add(..))
   */
  public void beforeAddStockItem(JoinPoint joinPoint) {
    .
    .
    .
  }

  /**
   * @After call(* Warehouse.add(..))
   */
  public void afterAddStockItem(JoinPoint joinPoint) {
    .
    .
    .
  }
}

This new version of the AuditingAspect now bears a strong resemblance to the AspectJ version.

Here is the declaration of the before advice from the AspectJ example:

before() : auditStockItem() {...}

AspectWerkz produces a similar construct using metatags. The metadata also identifies the join points for the advice.

/**
 * @Before call(* Warehouse.add(..))
 */
public void beforeAddStockItem(JoinPoint joinPoint) {...}

Metadata annotations replace the previous XML definition file, although a smaller file is still required to alert the AspectWerkz framework to the presence of aspects within the application.

Precompilation of AOP metadata information into the application makes it available at runtime for the AspectWerkz weaver. However, moving to J2SE 5.0 removes the need for the precompilation step.

The framework supports several weaving schemes, including bytecode and load-time weaving. AspectWerkz refers to these weaving schemas in terms of an operating mode: offline and online modes.

Offline mode is compile-time weaving and is a two-step process in AspectWerkz. The first step is the standard compilation of all source code with javac. The final step is the weaving process. Here, the AspectWerkz framework weaves the class files of the main application with the advice from the pertinent aspects. The result is a set of woven classes that run under any JVM, 1.3 or higher.

The online mode is more interesting, offering dynamic load-time weaving. In this mode, AspectWerkz hooks itself directly into the class-loading mechanism of the JVM. From this unique vantage point, AspectWerkz monitors class-loading activity and intercepts classes as they are loaded, weaving in advice at the bytecode level on the fly.

AOP frameworks like AspectWerkz are gaining recognition for the advantages they bring to the development of enterprise software. The binding of application servers with AOP frameworks has given rise to a new term, aspect-oriented middleware.

The J2EE platform already takes care of many major system-level crosscutting concerns for the developer, providing services for handling threading, security, persistence, transactions, and component-location transparency. Despite this long list of services, the J2EE platform employs a static model for the management of crosscutting concerns. In comparison to AOP-based frameworks, the J2EE model is rigid and inflexible, with new concerns requiring ad hoc solutions. Aspects promise a fluid and dynamic model for development, and experts in the field believe aspects will revolutionize application server design and the way we develop enterprise software.

Major J2EE server vendors are investing in AOP technology in order to take advantage of the new dimension aspects bring to the middle tier. IBM sponsors AspectJ, and formal support for AspectJ in WebSphere and WebSphere Application Developer (WSAD) is expected in the near future. Meanwhile, BEA has hired the creators of AspectWerkz to add dynamic AOP capabilities to its JRockit JVM. JBoss is currently forging ahead and have come up with its own AOP framework, JBoss AOP, which is an integral part of its application server.

Aspect-oriented middleware is at the (cross) cutting edge and may in the future represent a fundamental change in the way we develop enterprise software.

One approach to adopting AOP is to constrain the use of the technology solely to the development process by targeting development aspects. Development aspects are those aspects primarily of interest only to the development team. They offer an excellent opportunity to deploy AOP in the relative safety of the development environment without impacting production software.

Examples of development aspects include the following:

Development aspects serve only as an aid in the development process and do not target production-level systems. The dynamic nature of the AOP paradigm makes it very easy to remove development aspects from a system prior to its release into a production or preproduction environment.

Removing aspects from a system using AspectJ is simply a case of omitting aspects from the build process. For AOP frameworks that rely on load-time weaving, the production system has the AOP framework disabled.

Using AOP for only development aspects therefore offers a low-risk, incremental approach to introducing AOP to a project. The next step is to use AOP to implement production aspects of the system.

Unlike development aspects, production aspects form an integral part of the system delivered into production and actively contribute to the behavior of the system.

Taking AOP to this level carries a higher level of risk, but they are manageable by taking sensible steps in the introduction of AOP. These same steps apply when looking to introduce any new technology into a production environment.

A few common issues raised against the use of AOP in a production environment include the following:

A comprehensive testing process should address both of these issues, which is a standard approach when releasing any system into a production environment. You should also make the declaration of pointcut designators more accurate by enforcing rigorous coding standards.

Here are some ideas to consider if you are looking to deploy an AOP-based system into production:

By following a methodical and incremental approach to the adoption of AOP, you should be able to successfully make AOP-based applications a part of your enterprise environment.

AOP is not limited to just the OOP paradigm but is equally applicable to other programming types. Research is underway to investigate the suitability of AOP with procedural and rule-based languages. One area of interest is in the twinning of AOP and Model-Driven Architecture (MDA).

AOP is complementary to working with the MDA paradigm, and the combination of the two technologies may point to an exciting direction for the future of application development. Code resulting from an MDA process is particularly well suited for defining pointcuts, due to the ability of MDA tools to generate standard method signatures and adhere to coding standards. An MDA-generated application therefore forms an ideal candidate for evolving into a final system by weaving in advice.

Taking this scenario further, the MDA tool could generate an application built purely from system-level concerns. Business concerns would be implemented as aspects that could then be woven into the framework created by the MDA tool. Theoretically, this approach would result in a completely platform-neutral application, as the only handwritten code would be the business logic in the aspects.

Switching platforms—for example, moving to the new EJB 3.0 model—would simply involve plugging in a new MDA cartridge and redefining some of the pointcuts for the final weave. Indeed, the MDA cartridge could potentially generate the new pointcut declarations, leaving the developer with even less work to do.

The benefits of MDA with AOP are still just idle speculation, and more research is required to ascertain if the approach is workable. However, potentially the two paradigms have the ability to work well together, meaning the future of developing business software could lie in the skills of modeling and weaving.

AOP is an extensive subject, and it has been necessary to be very selective in order to cover the topic within the confines of a single chapter. Further information on AOP is available from the aspect-oriented software development Web site at http://aosd.net.

Ramnivas Laddad’s “I Want My AOP Series,” a three-part article on AOP based on AspectJ, can be found on the JavaWorld site. See http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html.