Anyone involved in the development of business-critical systems is aware of the importance of a conservative approach when adopting new technology. Production systems must be robust, and a good architect takes all necessary steps to ensure the stability and reliability of any software that underpins an organization's core business processes.
Although AOP has been undergoing research for over 10 years, the paradigm has yet to establish itself within the software engineering community to the same degree as OOP. Indeed, some members of the IT community claim that we have yet to establish a complete set of best practices for developing with OOP. Undoubtedly, many mistakes are likely with AOP as people attempt to realize the full potential of the paradigm. This was certainly the case with OOP.
Given the constraint that the ongoing stability of a production-level system is sacrosanct, this section offers some advice for safely introducing AOP to either a new development project or as part of an established system.
One approach to adopting AOP is to constrain the use of the technology solely to the development process by targeting development aspects. Development aspects are those aspects primarily of interest only to the development team. They offer an excellent opportunity to deploy AOP in the relative safety of the development environment without impacting production software.
Examples of development aspects include the following:
Development aspects serve only as an aid in the development process and do not target production-level systems. The dynamic nature of the AOP paradigm makes it very easy to remove development aspects from a system prior to its release into a production or preproduction environment.
The different types of system environments are described in Chapter 15.
Removing aspects from a system using AspectJ is simply a case of omitting aspects from the build process. For AOP frameworks that rely on load-time weaving, the production system has the AOP framework disabled.
Placing aspects under their own source directory or within their own package structure makes it easy to create build scripts that omit aspects from production builds.
Using AOP for only development aspects therefore offers a low-risk, incremental approach to introducing AOP to a project. The next step is to use AOP to implement production aspects of the system.
Unlike development aspects, production aspects form an integral part of the system delivered into production and actively contribute to the behavior of the system.
Taking AOP to this level carries a higher level of risk, but they are manageable by taking sensible steps in the introduction of AOP. These same steps apply when looking to introduce any new technology into a production environment.
A few common issues raised against the use of AOP in a production environment include the following:
A comprehensive testing process should address both of these issues, which is a standard approach when releasing any system into a production environment. You should also make the declaration of pointcut designators more accurate by enforcing rigorous coding standards.
Here are some ideas to consider if you are looking to deploy an AOP-based system into production:
By following a methodical and incremental approach to the adoption of AOP, you should be able to successfully make AOP-based applications a part of your enterprise environment.
AOP and Other Paradigms
AOP is not limited to just the OOP paradigm but is equally applicable to other programming types. Research is underway to investigate the suitability of AOP with procedural and rule-based languages. One area of interest is in the twinning of AOP and Model-Driven Architecture (MDA).
MDA is covered in Chapter 8.
AOP is complementary to working with the MDA paradigm, and the combination of the two technologies may point to an exciting direction for the future of application development. Code resulting from an MDA process is particularly well suited for defining pointcuts, due to the ability of MDA tools to generate standard method signatures and adhere to coding standards. An MDA-generated application therefore forms an ideal candidate for evolving into a final system by weaving in advice.
Taking this scenario further, the MDA tool could generate an application built purely from system-level concerns. Business concerns would be implemented as aspects that could then be woven into the framework created by the MDA tool. Theoretically, this approach would result in a completely platform-neutral application, as the only handwritten code would be the business logic in the aspects.
Switching platformsfor example, moving to the new EJB 3.0 modelwould simply involve plugging in a new MDA cartridge and redefining some of the pointcuts for the final weave. Indeed, the MDA cartridge could potentially generate the new pointcut declarations, leaving the developer with even less work to do.
The benefits of MDA with AOP are still just idle speculation, and more research is required to ascertain if the approach is workable. However, potentially the two paradigms have the ability to work well together, meaning the future of developing business software could lie in the skills of modeling and weaving.