There’s a movement afoot in the developer community, albeit a small one, to bring a new level of flexibility to today’s complex programs.
It’s called aspect-oriented programming (AOP), a less-than-radical idea that promises radical results for systems that use similar objects to interact with multiple classes — called cross-cutting concerns. Examples of these concerns would be
programs that need to handle logging, error handling, synchronization and optimization.
Today’s object-oriented programing (OOP) languages don’t handle these cross-cutting concerns — or aspects — very well from a design standpoint, which results in tangled code. AOP was developed to separate those concerns from the rest of the program to allow for more reusability and to avoid duplicating code.
So while the main program is designed from a top/down point of view, aspects would be introduced from the left/right and used by the program when needed.
For example, your company has a security policy that’s handled throughout an application. Rather than going through every function that handles security policy separately, it can be dealt with as an aspect that is shared throughout the program.
“The problem with OOP is that it locks you into one particular view of a system,” said Bill Chung, an engineer at IBM Research. “It lets you design a particular view of a system, but it locks you into that hierarchy and isn’t very dynamic.”
AOP doesn’t require a change in mindset to accomplish. It doesn’t require a new syntax or way of programming, unlike the switch from structured to object-oriented programming in the 80s, and it can be introduced into OOP applications incrementally. Thus, you don’t have to scrap you’re existing program to take up AOP.
There are three approaches AOP takes when used by programmers — language-based, at the metadata level, and code instrumentation at program runtime. All three are used to complete what researchers call
the aspect weaver.
Using AOP doesn’t deliver speed enhancements at compilation time or a drastic reduction in memory usage when its run. What it deliver, however, is a level of flexibility you can’t find in today’s larger programs. It lets programmers develop components (or aspects) of an object so changes can be made in one place, instead of throughout the hierarchies.
“It really gets at the question of hierarchies in cross-cutting,” said Dr. Gregor Kiczales, Aspect Oriented Software Association (AOSA) steering committee chair. “You can deal with inheritance if the objects are variations of the same kind of object. What cross-cutting is about is about cases where there is a commonality that cuts across the
hierarchy.
“Cross-cutting is really about the case that hierarchy doesn’t solve,” he added.
Kiczales is sometimes referred to as the inventor of AOP, though that’s something of a misnomer, as he’d be the first to tell you. The MIT graduate was the principal scientist at the Xerox Palo Alto Research Center, one of several organizations working on a viable AOP standard.
The research led to AspectJ, which because it came out slightly before the other projects, gained the widest adoption among the programming community and is one of the Java-based languages being used as a test bed for standardization through the Java Community Process (JCP).
Since that time, Kiczales has been a vocal member of the AOSA, which is the committee that sits around efforts in the Aspect Oriented Software Development (AOSD) community.
Kiczales and many of the early researchers used open-source Java as their platform for building on their idea of AOP. Unlike the proprietary source code found with Microsoft’s C++ and Visual Basic, programmers could draw on a huge community to help design the code that would work in conjunction with the OOP language.
As such, the Java community is further along in its efforts to a build commercial-grade AOP that’s ready for mainstream use. However, that doesn’t mean programmers will see it adopted into common practice anytime soon.
Although the AOSD has been working towards a solution since 1995, it still hasn’t become generalized enough for most programmers to understand and use confidently. According to many in the AOP community, which numbers only about 2,000 people worldwide, only about 10-15 percent of programmers are experienced enough to use AOP in an OOP environment.
What’s needed is standardization of the approaches used in AOP (at the language, metadata and runtime), said Jim Duggan, an analyst at Gartner.
“When you get right down to it, it won’t be called aspect-oriented programming when it hits the big time,” he said. “All these various approaches need to go through some standardization, maybe go through some packaging into something a novice or mid-level programmer can type and understand.”
Even though it might sound like AOP is taking too long to get developed in today’s world of instant information, the process is noticeably shorter than its predecessors, said Dr. Karl Lieberherr, AOSD 2004 PC chair and a professor at Northeastern University’s College of Computer and Information Science.
“It’s certainly went faster than object-oriented programming, which was invented in 1967, but still, 15 years is a good number of years,” he said. “Of course, in hindsight, you can always say we could have made this progress faster by doing this or by doing that. But it takes time to crystallize the important concepts.”
Lieberherr, who led the development team on Northeastern’s own AOP project — Demeter — at the same time as Kiczales was working at Xerox, said the advent of AspectJ has led to many advances in AOSD, though a lot of work remains.
“I think the biggest push came through the AspectJ team and the very good implementation of AspectJ that allows people to experiment with this technology and test it out and improve it,” Lieberherr said. “There’s still a lot of work to be done; I think we need higher-level tools than AspectJ. We need concern-specific Aspect languages; that’s how the field actually got started, by having a small number of concern-specific aspect languages.”
Programmers on Microsoft’s .NET platform have not been idle, though they are off to a late start. Wolfgang Schult is part of a team in Germany working on an AOP implementation called LOOM.NET. He said that while .NET is about two years behind efforts in the Java community, AOP is more accommodating on the Microsoft platform.
“Although there is no general difference between Java and .NET in terms of design options for AOP toolsets, on has to bear in mind that the .NET solutions typically are not restricted to a single programming language, as the Java-based solutions are,” he said.
This is because .NET programmers on the LOOM.NET project, who get financial backing from Microsoft, are able to use the binary .NET assemblies when developing their code. By working at this level, researchers’ efforts work just as well in C# and Visual Basic. Java programmers don’t have that luxury.
And while Java is a more popular language with academics and enthusiasts because of its open-source roots, many software developers in the U.S. focus on the .NET platform for their projects. Unfortunately, projects like LOOM.NET and WEAVE.NET are still “carried out in the context of a PhD. thesis,” said Schult.
“In all honesty, AOP has a lot of potential if it’s adopted in more places than just Java,” said James Shields, CEO of software developer Mabry Software, Inc. “I’d like to see this kind of thing added to C#.”
Independent software vendors like Shields, who want to see and use AOP, are in short supply these days, which is one of the biggest inhibitors to the growth of the AOP movement right now. While the technology is being used at the university level and within the bowels of research laboratories like Microsoft and IBM, AOP doesn’t get a lot of attention from the people who could provide the most growth opportunities for the platform: IT managers.
While Kiczales has seen a steady increase in numbers at the yearly AOSD conference, and Lieberherr has seen an uptick in the number of papers submitted to improve the technology, interest hasn’t percolated to the worker level.
This doesn’t have to do with AOP’s complexity, Schult said, despite what others may think.
“We had the same statements with the advent of object oriented programming languages,” he said. “Actually, if you look into today’s software projects then you will see that most of them are realized with OOP techniques. I think it has nothing to do with the knowledge of a programmer; it is more how accepted a programming technique is.”
What it has to do with is getting IT managers to feel comfortable enough with the technology to slowly integrate AOP into the design process. The technology’s inherent ability to be broken down into components makes that much easier — IT managers can test the improvements made to a program by creating one aspect within the program while keeping everything else the same, slowly building up a comfort level.
Ron Bodkin, a consultant at New Aspects of Security, wrote in his paper, “Commercialization of AOSD: The Road Ahead,” that many companies are doing exactly that:
“In the earliest phases, a lot of AOSD adoption has been achieved by advanced developers using it to achieve results on projects “under the radar” of management. However, for successful commercialization, business management must embrace it.”
Also needed, he writes is the need for a killer app that thrives on the technology improvements AOP can provide, including Web services, augmenting application servers and embedded and real-time computing.
“Its complex enough that I doubt we’ll see this suddenly blow into the market across huge numbers of people quickly,” said Gartner’s Duggan. “I think it’s more likely we’re going to see specific applications of it sneak in under different names and cloaks and gradually get to the point where people are using it like object-oriented programming.”