Adopting Aspects | Rapid J2EEв„ў Development: An Adaptive Foundation for Enterprise Applications

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.

Development Aspects

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:

Tracing.
Adding trace statements to the code to follow the flow of a specific section of the application is an effective debugging method and supplements the use of a debugging tool.
Profiling.
AOP enables the instrumentation of the application with code to gather performance data from the executing program. Profiling techniques identify bottlenecks within the application that prevent the system from achieving its performance objectives.
Testing.
In addition to injecting advice for profiling applications, AOP can add advice as part of a white-box testing approach. Advice in this context reveals the internal state of the class under test.

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.

Tip

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.

Production Aspects

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:

System performance degradation due to runtime weaving
Emergent system behavior resulting from inaccurate pointcut declarations

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:

Experiment with development aspects.
Define coding standards for working with aspects.
Ensure all staff are knowledgeable in the use of AOP techniques.
Build prototypes to validate the selected AOP framework from both a functional and performance perspective.
Thoroughly test the system and the configuration of the AOP framework before deploying 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.