Aspect-oriented programming comes of age
Monday June 09, 2003
- by Joab Jackson -
This past weekend's 1.1.0 release of the AspectJ Java extension, as well as the recent 4.0 release of the popular open source JBoss development platform, shows that the once academic concept of aspect-oriented programming is beginning to take root.
The core advantage of AOP is simple. It brings more powerful referencing mechanisms to programming.
"It has the ability to refer to things that happen in the program outside the very local scope," said Cristina Videira Lopes, one of the developers of the AOP methodology and the AspectJ language that embodies it.
Hashed out in the mid-90s by a team at the Xerox PARC (Palo Alto Research Center) lab, AOP, as an extension to object-oriented programming, at first met with indifference, if not criticism. But with the advent of more enterprise-wide Java-based implementations, the basic ideas surrounding AOP seem to be taking hold. In particular, programmers are finding that AOP tools can complement Sun Microsystems' Enterprise JavaBeans, or even, in some cases, eliminate them altogether.
Since the late 1980s, OOP has answered multiple needs in the evolving computer landscape. Graphical user interfaces demanded the building of multiple windows. Database use grew more complex, and data was being called by more processes.
By coupling the data with the methods to access the data as well as breaking work into smaller reusable modular chunks, OOP helped programmers avoid a lot of tedious work. But however well the modular approach worked, programmers from time to time found themselves writing the same kinds of functions for handling data over and over again. These functions were labeled cross-cutting functions. Unlike the core functions of a program, cross-cutting functions are called on by different objects across a system.
AOP was developed as a way to place these common tasks in a single location. Of course OOP is itself all about reusability. But OOP reusable components usually fall under specific classes. AOP differs in that it lets a specific object support multiple inheritance. Instead of compiling a number of functions into a class, AspectJ takes the functions, called advice, and groups them into what is called an aspect. A single location in the program defines all the places where an advice is applied.
"Aspect-Object interaction differs from Object-Object interaction and other traditional programming paradigms in that with the traditional approaches, all behaviors of the objects are encapsulated in the objects themselves... In the AOP environment ... a part of the object's behavior can be defined in an aspect outside of the object without the object having to request the behavior in any way," according to a 1999 patent filed by Xerox Corp. for the AOP concept.
Authorization, logging, thread-safety, caching, business rules, and boundary and error checking are a few of the cross-cutting concerns that can be addressed by AOP.
"Using object-oriented technology, it is not possible to implement these in a modular way," said Ramnivas Laddad, author of the book AspectJ in Action: Practical Aspect-Oriented Programming, to be released in July by the Manning Publications Co.
Take authorization for instance. Using OOP techniques, programmers would have to plant the same authorization code individually in each module that needs authorization functionality. This can be problematic. If a change needs to be made to the authorization procedure, all the different modules using authorization would need to be updated. With AspectJ, the change can be made once.
The seeds of AOP came from Xerox's Palo Alto Research Center between 1995 and 1997. The work was supported by the Defense Advanced Research Projects Agency, the National Institute of Standards and Technology, and by Xerox itself. Led by Gregor Kiczales, the original team also included Lopes, John Lamping, Anurag Mendhekar, Chris Maeda, Jean-Marc Loingtier, and John Irwin
Lopes, in her paper "Aspect-Oriented Programming: An Historical Perspective (What's in a Name?)," recalls how AOP germinated. (The paper will be part of an upcoming book, Aspect-Oriented Software Development, to be published by Addison Wesley later this year.)
AOP came about as a result of looking at ways to build clean design structures for complex software. At the time, ideas of distributed computing were raising a number of concerns with programmers. How could developers deal with concurrency, real-time constraints, location control, persistence, and failure recovery while keeping their computational algorithms and basic functionality intact?
Incorporating solutions directly into the program code proved unnecessarily complex. so the team looked at meta-level programming as a way to separate some functions from the basic program algorithms. Metaobjects could intercept messages to and from objects, checking for synchronization constraints, real-time specifications, migrate parameters, and other factors. In this way, the basic objects could be written without worrying about special purposes.
A number of different languages and toolsets then being developed at the Xerox research lab took this approach. The RG image processing software being developed was an attempt to optimize memory usage by checking messages for the loop structures they invoked. Annotated MatLab, AML, sought to optimize MatLab by augmenting its code with special directives for the language processor. The Evaluation Time Control Meta Language provided directives that a programmer could use to instruct the language processor to evaluate sections of code at run-time or compile-time.
Lopes, who joined the team in 1995 as a visiting student, herself developed a language called DJava as an outgrowth of her dissertation (the "D" stood for distributed). It was written to address two specific problems, concurrency and remote parameter passing.
In working with concurrency, a program should be able to check to see if one object is closed before another object is activated. For remote parameter passing, when an object is invoked remotely, only certain preselected fields could be returned.
"I was trying to reorganize the code so that certain concerns that were tangled in Java could be untangled," wrote Lopes. "Based on what distributed programs looked like, usually messy, I was trying to reorganize the code so that certain concerns that were tangled in Java could be untangled."
However, unlike the other PARC project leaders, Lopes felt that metaclass programming would be overkill. A compile-time process should work better than a run-time model.
"It seemed awkward to me that in order to say this I would have to define metaclasses, instantiate and associate a metaobject for every base object, trap every message sent to the base objects and execute their metaobjects code at those points," Lopes wrote.
Instead, Lopes developed a simpler referencing mechanism, one in which directives were expressed separately from the classes, and referred to objects' operations by name. This ran against the grain of OOP, which required each object to specify its dependencies. Instead, Lopes' modules would impose themselves on other modules, as she recalled in her paper.
Although DJava was first implemented only to handle concurrency and remote parameter passing, the PARC team quickly saw it as a base for expanding AOP to a more general level. Hence the beginning of AspectJ, the first version of which was released in early 1998. Built as an extension of Java, AspectJ served as a model to industry of how AOP could operate.
By the year 2000, AspectJ compilers could handle a few hundred classes. Programmers in the industry (as opposed to just grad students and other researchers) started using the AspectJ extension.
It didn't always meet with success, however. Lopes admitted that the early versions of the extension were difficult to use. In the March-April 2003 issue of American Scientist, an article entitled "The Post-OOP Paradigm" noted two researchers' attempts to use AspectJ to build a transaction processing system, with limited results. The key requirement, author Brian Hayes wrote, "is that transactions be executed completely or not at all."
"They found it difficult to cleanly isolate this property as an aspect," he concluded.
Nonetheless, as EJB (Enterprise JavaBeans) grows in popularity, programmers are finding distributed computing-friendly AOP-based tools can add functionality to enterprise deployments. AspectJ is being increasingly used for such acts as debugging, enforcement and verification, load balancing, and synchronization.
Laddad said he sees three early adopters for AspectJ in the enterprise software space. One would be those who need to do enterprise software deployment but aren't quite ready for an EJB package of server components. With EJB, a program is bound to an application server, which can cause compatibility issues when the time comes to change over to another server or even to upgrade. Also, the industrial strength of EJB isn't needed for all enterprise applications.
Another interested group might be EJB users looking for functionality that EJB doesn't have, such as logging and cross-cutting business rules. A third use would be policy enforcement, allowing programmers to compile an application using AspectJ to insure the code will adhere to rules such as EJB specs.
"The idea is that if you write a few aspects that capture all the rules, and you compile your application with these application, the compiler will tell you if you are doing something wrong. You are putting your own error-checking code in," Laddad said. He said a good programmer can get up to speed on the fundamentals of AspectJ within a few days.
In her paper, Lopes uses an example of a program that tracks timing and billing for conference calls as an example of one that could benefit from an AOP approach. Different callers would evoke the timer at different intervals, some from the start of a call, some not at all, others only when they join a conference call. A specific module can hold the information about what conditions would evoke the timing feature, allowing the programmer to make changes without touching the basic classes.
And the use of AspectJ is not limited to enterprise systems. It could also be used to build desktop software systems and real-time systems, Laddad said.
In December 2002, PARC transferred AspectJ to Eclipse, an open source software development project (although some of the key technologies are under patent from Xerox). AspectJ-1.1.0, released June 6, includes new features such as support for compiled aspect libraries distributable in .jar form and the ability to apply aspects to any .jar file.
Some issues still need to be addressed -- for instance, the issue of whether an aspect can access private variables. As one programmer pointed out, if an aspect can access a private variable then "Isn't this a way of subverting encapsulation?" On the other hand, if it can't, then isn't AspectJ limited in its effectiveness?
"That issue has been much debated over the years, it can be both ways," Lopes said, noting that a resolution of the problem has yet to be worked out.
Although AspectJ is heavily tied up with AOP, the extension is far from the only implementation of AOP. At last check, the Aspect Oriented Software Development page lists 38 platforms, supporting languages such as C++, C#, Python, Perl, and Smalltalk.
On the commercial side, the JBoss Group claims its JBoss application server is the first J2EE-based application server to use the AOP framework. Version 4.0 of JBoss was released June 2.
AOP brings JBoss some competitive advantages in the application server market. The press release for the 4.0 version touts object persistence, caching, acidity, remoteness, transactions, and security services, all without the need for writing EJBs. It also mentions that developers can write Java objects and then add enterprise-type services later in the development cycle without modifying the original objects.
In the white paper Why I Love EJBs, JBoss founder Marc Fleury explained how the AOP methodology allowed his development team to offer IJB services a la carte, providing a modularity he said most EJB packages don't offer. In particular, standalone interceptors "take invocations coming in, they look at the context of the invocation (for example, the configuration of the transactional attribute for a given method) and apply their logic to the invocation," he wrote. The advantage to this approach is that "we allow you to develop middleware technology directly in your IDE."
"We give you the hooks to simply specify the interceptor stack you want for a given component."