A new aspect to programming?

At the other end of the software spectrum are advocates of new techniques like Aspect Oriented Programming (AOP), who are 100 percent serious when they say that real coders want to be as productive as possible so they can keep their jobs, be more productive and re-use code efficiently rather than re-invent the wheel every day of their working lives.

So where did AOP come from?

For many years, object orientation (OO) was the vanguard of this movement, but even OO’s idea of creating discrete pieces of code for different functions did not mean that coders were freed from re-writing some parts of an application over and over again.

Researchers at the famed Xerox Palo Alto Research Lab (PARC) were examining the limitations of OO in the early 1990s and explored the idea of new ways programming languages might help programmer productivity by easing modularisation of code. At around the same time, then PhD student Cristina Lopes and others at Northeastern University in the USA were pursuing similar thinking. Eventually, the USA’s Defense Advanced Research Projects Agency (DARPA) noticed the work, injected funding and encouraged collaboration between PARC and Northeastern, who combined to create AspectJ, a set of extensions to Java that programmers can now use to apply AOP.

AOP’s core idea is “separating the business logic in an application from the common services that support it,” according to Adam Magee, a Senior Solution Architect with Avanade, a technology integrator that specialises in Microsoft technologies.

AOP practitioners call those common services “crosscutting concerns,” as the functionality they offer cuts across the needs of many objects in an application.

“Cross-cutting concerns could be instrumentation, auditing, logging, security checks or exception handling,” says Magee, who has applied AOP to many projects. “Writing code to interface with these services can be very time consuming and it can take a lot of time for a developer to learn how to do it.” “It also distracts them from solving the business problem—which is where the value is—and diverts them to delving around inside complex operating system plumbing.”

Benefits of AOP
AOP aims to get around these problems by separating the job of writing cross-cutting concerns—also known as “aspects”—from the job of writing objects that comprise business logic, then offering structures so that an application can simply use the functions of aspects without needing to rebuild or recode anything at all.

The technique aims to save time by allowing developers to create a definition of the cross-cutting concerns an application requires to suit every object that requires it. So instead of, for example, writing a logging system for each object—a practice AOP characterises as “scattering”—AOP practitioners would suggest that during the design phase of a project, developers should define the logging requirements for every object with the application and then create a single logging tool that performs all the logging functions that will ever be required by any part of the application.

AOP’s proponents say the benefits of this approach are several. Firstly, the effort that goes into defining all of an application’s requirements for a service like logging means the services are better-defined, better-coded and emerge offering richer functionality. It also addresses problems created when code is written to perform more than one function, as changes to one function can impact the other, a problem AOP dubs “tangling”.

Secondly, making the effort to create discrete aspects allows a development team to assign an expert to the job, so that the best people for the job can exercise their skill and experience.

A third benefit is consistency. In a typical object-oriented project different coders will often start with the same code to create a service like logging, then each diverge in their individual implementations of the logging services required to support an individual object. By creating a single piece of code, AOP offers a simple route to consistency, which enhances future re-usability and eases maintenance: Instead of re-writing logging routines throughout an application AOP makes it possible to re-write just the logging aspect and have the new functionality serve the entire application.

All of these benefits reduce the number of lines of code that need to be written, saving time, controlling costs and freeing resources for more valuable activities than writing a logging program.

AOP at work
“Traditionally when you design an application you start by defining the business functions: all the things you need the application to do,” says Brad Kasell, an engagement manager for emerging technologies at IBM.

“But then there is also all the implied stuff that never gets written in the spec, so developers end up discovering that an application needs different types of logs in different places, and needs to write to them at different times.”

“AOP means they finally have an opportunity to ask how to apply plumbing across the board so you write it once to serve the whole application.”

AOP projects therefore start with developers identifying the orthogonal functions that all objects will require. As the objects are developed, coders pinpoint “crosscut points” where each object will need to call on an orthogonal function. Instead of coding a logging service into the object, programmers instead write a “point cut” which “weaves” the aspect into the object.

The result is an application comprised of objects and a separate pool of code that delivers orthogonal services, with the objects calling on the services as required.

How to code it
Putting AOP to work is relatively simple, as a multitude of tools are available.

Open source software dominates the field. AspectJ, originally designed at PARC, was turned over to the Eclipse Foundation in 2002 and is now the most popular AOP tool.

AspectJ bills itself as “a seamless aspect-oriented extension to the Java programming language” and offers new syntax to define, create and use aspects. AspectJ can be implemented in almost any programming tool. The other most common AOP tool is AspectWerkz, created by two BEA employees and released under the lesser GNU public license.

In January 2005, AspectJ and AspectWerkz agreed to combine their efforts to create a single tool that takes the best from each project.

Commercial software vendors like JBoss also offer AOP products. The company’s JBoss AOP was released in late 2004 and offers an aspect-oriented framework and a library of aspects.

In the .NET world, things are less well-developed. In January 2005 Microsoft released an Enterprise Library offering seven different “application blocks” that Avanade’s Magee says can be considered aspects and accessed using the Attributes feature of Visual Studio .Net. Loom is another project. But the approach taken by these tools is by no means unified. AspectJ’s approach is to extend Java. An opposing camp argues that language extensions are inherently cumbersome and that AOP can be implemented using XML metadata to define cross cuts and invoke objects.

Limitations?
These conflicting approaches and the fact that no major IDE vendor has made AOP a “formal” part of their tools leads many to feel that while AOP’s central ideas are powerful, it is still immature. “I believe AOP has not quite hit total mainstream programming so a lot of people aren’t sure how to put it into their everyday work,” says Michael Smith, director of technology for BEA’s Technology Office. “It is somewhere in between mainstream and leading edge.”

And while it is in this limbo, its true potential is somewhat unknown.

John Tirsen, a consultant with development mentoring company ThoughtWorks says he has used AOP in many projects, but that its idea of modularising services is not entirely new. “It’s been done before with things like CORBA interceptors,” he says. “The more contentious issue is whether it can be used for cross-cutting business logic.”

BEA’s Smith also sees untapped potential. “Down the road we can see you might want to adjust the behaviour of middleware using AOP, maybe to instruct the middleware layer to do different things at different times” in accordance with different business rules. “We are doing a lot of that work in the VM to make that happen.”

While this kind of work sounds exciting, no-one is suggesting any timetable for their delivery, implementation or widespread adoption.

Yet the AOP genie is well and truly out of the bottle.

“Six months ago no-one ever asked me about AOP,” Smith concludes. “Now you can fill AOP sessions at a conference and clients ask without me ever bringing it up,” a sure sign that whether or not you want to write your own device drivers, AOP will deserve investigation in coming months and years.