This month, I’m writing from the annual Aspect-Oriented Software Development (AOSD) conference, which was held in Lancaster, England, on March 22-26. This third conference has been the most vibrant one thus far, with excitement swirling around applications and commercial adoption.
Setting the conference’s tone in his keynote, Dr. Daniel Sabbah, vice president of IBM Development and Software Group Strategy, announced Big Blue’s commitment to use and support AOP in its products.
In addition to researching its own AOP tools for years, IBM has been evaluating AspectJ internally for nearly two years. Sabbah outlined the kinds of flexibility and quality benefits IBM has achieved using these tools: The WebSphere product line, for example, uses AspectJ to modularize crosscutting concerns and enhance quality, conformance and flexibility. It was very exciting to hear the head of IBM’s software division say that aspect-oriented technology is critical to his business.
The Audience: AOP Brain Trust
|Bashar Nuseibeh (left), professor of computing at the Open University, spoke on crosscutting requirements. In his keynote, Daniel Sabbah (right), vice president of IBM Development and Software Group Strategy, discussed Big Blue’s commitment to aspects.|
The first two days were devoted to tutorials and small workshops. The tutorials covered AspectC++, AspectJ, AspectWerkz and JBoss, as well as a more general study of AOP in enterprise software. At AOSD, tutorials are always presented by tool designers and implementers: Experts included Bill Burke, JBoss chief architect; Jonas Bonér, the lead designer and implementer of AspectWerkz; and Erik Hilsdale and Mik Kersten, two AspectJ designers. These interactive sessions allowed participants to investigate not just the whats, but also the whys and hows of the tools.
The research workshops included middleware and operating systems, dynamic aspects, security and the use of aspects at the design level. Over the past year, researchers have paid more attention to AOP applications; this focus was reflected in the workshop presentations and discussions, with such topics as using aspects to enhance or replace Enterprise JavaBeans receiving extensive discussion.
The newest commercial AOP tools include support for dynamic AOP, but—despite the consensus on the importance of dynamic aspects—the best way to offer that functionality has yet to be determined. The dynamic aspects workshop was largely devoted to addressing near- and long-term questions about implementing dynamic AOP.
The Main Event
The main conference began on Wednesday with the opening keynote from IBM. For the rest of the day, much of the hallway discussion revolved around what kinds of AOP support attendees would like to see in the IBM Rational product family.
The day also included a panel discussion moderated by Brian Barry, of the Canadian firm Bedarra Research Labs. The panelists—Bonér, Burke, Adrian Colyer (who leads AspectJ development at IBM), Jon Tirsen of ThoughtWorks and myself—primarily fielded questions from the audience.
One question had to do with the pace of adoption. According to Colyer, IBM has been carefully supporting the rollout of AspectJ into internal projects, following the “go slowly; development aspects before production aspects” approach. However, some projects are now jumping right into writing development aspects when appropriate.
Another audience member asked whether it was time to standardize AOP in the Java world. The panelists concurred that important standardization is already happening. Tool developers are striving to make similar tool elements work the same way, converging on AspectJ’s pointcut language as a common ground. Everyone appreciates that while it’s good for users to continue exploring new features, no one is well served by meaningless differences. So all the tools are moving toward spelling execution pointcuts the same way, even as they continue to explore different solutions to dynamic aspects and other issues.
The last day of the conference opened with a keynote by Bonér, who detailed AspectWerkz’s main design goals and offered a careful comparison to AspectJ, discussing the rationale, pros and cons of each difference. In the future, he said, the company will turn its energies to developing an “Aspect Container” and continuing the development of runtime weaving support.
Providing a venue where the developer of an important tool can present a frank assessment of his product’s strengths and weaknesses is one of the conference’s invaluable benefits. Researchers noted issues for future work, and Bonér gleaned some ideas about addressing short- and long-term problems—and we all learned more about AOP. I look forward to similar presentations from the growing number of commercial AOP experts next year.
A Sense of Cooperation
This same spirit was reflected in the strong sense of goodwill among BEA, IBM and JBoss. All attended each other’s tutorials and demonstrations, and the questions they asked were clearly in the spirit of making AOP a more competitive technology, rather than trying to poke holes in each other’s tools.
The AspectJ, AspectWerkz and JBoss developers had extended conversations about maintaining this spirit of competition while continuing to compete as appropriate—a.k.a. coopetition. With or without an official standard, there’s every reason to believe that developers will identify a clear AOP kernel that will enable their users to understand the most—and least—stable parts of their tools.
This was the best year yet at the AOSD Conference, fueled by the palpable energy of AOP’s most serious commercial adopters. The 2005 conference will be in Chicago, and it should be even more exciting. For more information, including slides from this year’s conference and plans for next year’s event, see aosd.net.
| Refactoring Support
R&D efforts aim to eliminate conflicts between OOP and AOP.
When developers first learn about AOP, they often have questions about refactoring. Once people start seeing aspects, they want tools that can help them find existing tangled aspects and refactor them into modular code. Another common question relates to what happens to aspects when existing OO refactorings are used—pointcuts can be broken if a refactoring moves or renames methods and classes.
At the conference, we saw results of current tool development as well as long-term research efforts that will help on both fronts. For example, future releases of the Eclipse AspectJ Development Tools Subproject (AJDT) plug-in will ensure that OO refactorings don’t break AspectJ code. And researchers are helping with the next generation of tool support by working on aspect-oriented refactorings, ranging from fairly straightforward to quite sophisticated means of migrating from OOP to AOP—a promising area for open source developers interested in contributing to AOP tools.
Gregor Kiczales led the Xerox PARC teams that developed aspect-oriented programming and AspectJ, and is a leading AOP evangelist based in Vancouver.