allowing for advice to be invoked as required. The slight drawback of dynamic AOP is that, typically, it
does not perform as well as static AOP, but the performance is steadily increasing. The major benefit of
dynamic AOP implementations is the ease with which you can modify the entire aspect set of an
application without needing to recompile the main application code.
Choosing an AOP Type
Choosing whether to use static or dynamic AOP is actually quite a hard decision. There is no reason for
you to choose a single implementation exclusively, because both have their benefits. As a matter of fact,
starting from version 2.0, Spring already provided a tight integration with AspectJ, allowing you to use
both types of AOP with ease. In general, the static AOP implementations have been around longer, and
they tend to have more feature-rich implementations, with a greater number of available joinpoints.
Indeed, Spring supports only a subset of the features available with AspectJ. Typically, if performance is
absolutely critical or you need an AOP feature that is not implemented in Spring, then you will want to
use AspectJ. In most other cases, Spring AOP is ideal for what you are trying to achieve. Make sure you
are aware that many AOP-based features are already available in Spring, such as declarative transaction
management. Reimplementing these using AspectJ is a waste of time and effort, especially since Spring
has tried-and-tested implementations ready for you to use.
Most importantly, let the requirements of your application drive your choice of AOP
implementation, and don't restrict yourself to a single implementation if a combination of
implementations would better suit your application. In general, we have found that Spring AOP is less
complex than AspectJ, so it tends to be our first choice. If we find that Spring AOP won't do what we
want it to do or we discover during application tuning that performance is poor (for example, when
profiling the application using a Java profiler, the profiling result indicates that much time was spent in
Spring in generating the dynamic proxy for the defined aspects), then we move to AspectJ instead.
AOP in Spring
You can think of Spring's AOP implementation as coming in two logical parts. The first part is the AOP
core, which provides fully decoupled, purely programmatic AOP functionality (Spring called it the Spring
AOP API). The second part of the AOP implementation is the set of framework services that make AOP
easier to use in your applications. On top of this, other components of Spring, such as the transaction
manager and EJB helper classes, provide AOP-based services to simplify the development of your
application. In this chapter, we focus solely on the basics of the AOP core. The framework services and
the advanced functionality of the core are covered in Chapter 7.
Spring AOP is really a subset of the full AOP feature set, implementing only a handful of the
constructs available in implementations like AspectJ. Don't be fooled into thinking Spring AOP is not
useful, however. Indeed, one of the most powerful aspects of Spring AOP is that it is so simple to use
because it is unencumbered with extraneous features that you often do not need. The implementation of
only a subset of the AOP feature set is a specific design goal of Spring, allowing Spring to focus on simple
access to the most common features of AOP. To make sure you are not left without the AOP features you
need, Spring's designers designed Spring to fully integrate with AspectJ.
The AOP Alliance
many open source AOP projects, including Rod Johnson of Spring, to define a standard set of interfaces
for AOP implementations. The AOP Alliance is being very conservative, resisting the temptation to over-
constrain AOP while it is still growing, and as a result, it has defined interfaces for only a subset of AOP
features. Wherever applicable, Spring uses the AOP Alliance interfaces rather than defining its own. This
Search WWH :
