I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

A Tour of AOP

  • submit to reddit

The AOP methodology is just that—a methodology. In order to be of any use in the real world, it must be implemented, or realized. As with any methodology, it can be implemented in various ways. For example, one realization of the OOP methodology specification consists of the Java language and tools such as the compiler. In a similar manner, each realization of AOP involves specifying a language or a framework and associated tools. Like any other programming methodology, an AOP implementation consists of two parts:

  • The language specification describes the language constructs and syntax to express implementation of the core and crosscutting concerns.
  • The language implementation verifies the code’s adherence to the language specification and translates the code into an executable form. This is commonly accomplished by a compiler or a runtime agent
This article is based on chapter 1 from AspectJ in Action, Second Edition by Ramnivas Laddad. Courtesy of Manning Publications. All rights reserved.

The AOP language specification

Any implementation of AOP must specify a language to implement the individual concerns and a language to implement the rules for weaving the concern implementations together. While I talk in terms of two separate languages, an AOP system may not distinguish between the two parts. This is likely to be the case in future AOP languages. Let’s take a closer look at these two parts.


As in other methodologies, the concerns of a system are implemented into modules that contain the data and behavior needed to provide their services. For example, a module that implements the core part of the caching concern will maintain a collection of cached objects, manage the validity of the cached objects, and ensure bounded memory consumption. To implement both the core and crosscutting concerns, we normally use standard languages such as C, C++, and Java.


Weaving rules specify how to integrate the implemented concerns in order to form the final system. For example, once you implement the core part of the caching concern in a module (perhaps through a third-party class library), you need to introduce caching into the system. The weaving rule in this case specifies the data that needs to be

cached, the information that forms the key into the cache storage, and so forth. The system then uses these rules to obtain and update cache from the specified operations.
The power of AOP comes from the economical way of expressing the weaving rules. For instance, to modularize tracing concern in for listing 1, you can specify to log all the public operations in the system in just a few lines of code

Listing 1: Business logic implementation along with crosscutting concerns

public class SomeBusinessClass extends OtherBusinessClass { 
... Core data members
... Log stream #5
... Cache update status #3
... Concurrency control lock #2
... Override methods in the base class

public void someOperation1(<operation parameters>) {
... Ensure authorization #1
... Lock the object to ensure thread-safety #2
... Ensure cache is up-to-date #3
... Start transaction #4
... Log the start of operation #5
... Perform the core operation
... Log the completion of operation #5
... Commit or rollback transaction #4
... Unlock the object #2
... More operations similar to above addressing multiple concerns

#1 Security check
#2 Concurrency control
#3 Caching
#4 Transaction management
#5 Tracing
For example, here is weaving specification for the tracing aspect.

  • Rule 1: Create a logger object.
  • Rule 2: Log the beginning of each public operation.
  • Rule 3: Log the completion of each public operation.

This is much more succinct than actually modifying each public operation to add logging code. Since the tracing concern is modularized away from the class, it may focus only on the core concern as follows.

public class SomeBusinessClass extends OtherBusinessClass {
... Core data members
... Override methods in the base class
public void someOperation1(<operation parameters>) {
... Perform the core operation
... More operations similar to above

Compare this class with the one in listing 1.1: All the code to perform tracing—the ancillary concerns from the class’ point of view—have been removed and only the core business logic remains. As we will see in the next section, an AOP implementation will combine the classes and aspects to produce a woven executable.

Weaving rules can be very general or very specific in the ways they interact with the core modules. For example, in the previous logging example, the weaving rules did not need to mention any specific classes or methods in the system. On the other end of the spectrum, a weaving rule may specify that a business rule that is to be applied to only a specific methods, such as the credit and debit operations in an Account class or the ones that carry the @ReadOnly annotation. The specificity of the weaving rules determines the level of coupling between the aspect and core logic.

The language used for specifying weaving rules could be a natural extension of that language or something entirely different. For example, an AOP implementation using Java as the base language might introduce new extensions that blend well with the core Java language, or it could use a separate XML-based language to express weaving rules.