Aspect oriented programming with Java

A practical introduction

Combat fraud and increase customer satisfaction

Writing software is a complex business - not only do you have to get the enterprise logic of the application correct, typically you also have to deal with multiple other concerns at the same time, such as "what should happen if something goes wrong", "how should I make sure we know what is happening during execution", "how to enforce security throughout my application" and in some languages "how do I handle memory" or "when should I free up memory", etc.

In Java, of course, we have already been able to move much of the responsibility, and thus the implementation of, memory manage and garbage collection into the Virtual machine. However, Java software still often needs to handle multiple concerns within the same body of code. A classic example is the use of user validation code and logging code within a Java class that performs some form of system behaviour (such as requesting a book from a library etc).

Such cross cutting concerns are one of the underlying motivators behind what is know as Aspect Oriented Programming (or AOP). The basic idea behind AOP is that each concern within an application should be implemented within its own independent module (or Aspect). Thus, a logging module only deals with logging and isn't tangled up with other business logic.

The Basic Concepts of AOP

Software development has progressed a long way in the last 20 or 30 years. Twenty years ago it was not uncommon to find assembler and high-level code mixed together in the same (pages long) source code listing. However, we have improved awareness of the benefits of highly cohesive, but loosely coupled code, we have accepted the need for modularity in our systems, and we have adopted (within Java at least) Object Orientation as a basic software engineering technique.

However, I can still find myself looking at a source code listing and having to try to pull out the basic business logic, from all the "stuff" that sits around it.

All this "stuff", such as calls to logging components, authentication checks, exception handling, transaction management, etc, is all very important within any large software system. However, it adds to the fog that can surround a potentially simple piece of business logic.

Interestingly, one of the compelling arguments for making techniques such as Automatic Garbage Collection and Memory Management mainstream was that it separated out the implementation detail of managing memory from the business logic required by an application. Mixing the two made software more difficult to read, understand, and maintain; by placing the memory management in the background, the core business logic was that much simpler. This is essentially the premise behind AOP.

Let's take logging as an example. It's quite possible to design and implement a logging subsystem (indeed many have done this for Java including the Apache Log4J Logging framework).

However, the problem is that such a subsystem just provides the ability to log; it says nothing about where and when you should log system behaviour. To do this you most go through your software system and add such logging statements to appropriate points within methods. The end result is that the user of the logger needs to know that it is available, what its API is and, of course, must decide where to place the logging statements.

In turn the pure business logic methods are now augmented by additional (non-business related) method calls. As this process may be repeated for numerous such subsystems, the initially clean code may now be far more complex. This, in extreme cases, may make it more difficult to understand the underlying, relatively simple, business logic.

Logging here is an example of a cross cutting concern. That is, it is an aspect of the systems behaviour that cuts across many other modules. AOP allows Logging to be implemented as a completely self-contained module that is dynamically linked with the initial business logic in such a way that the original source code is unchanged. The self-contained, or stand-alone modules, are referred to as Aspects within AOP.

AOP programs can achieve the linking of the Aspect with the pure business logic code in a number of ways. For example, a pre-processor could be used to produce a combined program that is then compiled to produce the runtime executable (this was the approach originally used by AspectJ back in 2001). Another approach is to provide some form of post compilation modification.

In Java';s case, this means modification of the byte codes generated for classes such that links to an appropriate Aspect are incorporated into the byte codes. Such byte code weavers can be deployed during the build process or, if the weave model is per-class, during class loading. AspectJ has evolved from providing per-class bytecode weaving in 2002 to advanced load-time integration form 2005. The final approach is to augment the underlying execution environment (in Java's case the JVM) so that it understands AOP language elements directly.

AspectJ for Java

AspectJ is currently the most complete implementation of an AOP language for Java. In practical terms, it is an extension to Java that treats AOP concepts as first-class elements of the language. It allows aspects to be implemented as part of a Java based application using familiar Eclipse based tools.

As AspectJ is an extension to Java, Java is the implementation language for the constructs that comprise an Aspect. That is, you use Java to implement whatever behaviour the Aspect should provide. A set of rules is then used to determine how to weave the aspect into the main body of your Java application. These rules are implemented by pointcuts, join points, and advice. A pointcut specifies what join points there are. In turn, a join point defines where in a Java programs' execution the aspect should be applied and advice is the implementation of what to do at that point.

The actual syntax of the AspectJ language is Java-like, details of which can be obtained from the AspectJ home page.

High performance access to file storage

Next page: A simple example

More from The Register

next story
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
Red Hat to ship RHEL 7 release candidate with a taste of container tech
Grab 'near-final' version of next Enterprise Linux next week
prev story


Designing a defence for mobile apps
In this whitepaper learn the various considerations for defending mobile applications; from the mobile application architecture itself to the myriad testing technologies needed to properly assess mobile applications risk.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.