//enterprise java /
Who Needs Aspect-Oriented
Programming?
In Java EE, there is rarely an obvious use case for AOP.
ADAM BIEN
JAVA IN ACTION
According to Wikipedia, aspect- oriented programming aims
to separate reusable functional-
ity from the business logic: “In
computing, aspect-
oriented program-
ming (AOP) is a pro-
gramming paradigm
which aims to increase
modularity by allow-
ing the separation of
cross-cutting concerns.
AOP forms a basis for
aspect-oriented soft-
ware development.”
AOP was a hot
topic a few years ago,
but it never really took
off in J2EE—and for
good reason.
Note: A sample Java EE project
for this article (AOPandJavaEE) is
available on the Project Kenai
Web page.
1998 were aspects. The developer
had to develop the Bean class and
the Remote and Home interfaces
but none of the cross-cutting
aspects. Threading,
pooling, security,
transactions, ses-
sion handling, and
even persistence were
configurable aspects
cleanly separated from
the business logic. The
cross-cutting function-
ality was configurable
in the early EJB 1.0 days
with POJOs.
With the advent of
EJB 1. 1 and J2EE, Java
classes were replaced with XML,
and the recent Java EE 5 and Java
EE 6 specifications made XML
optional. You can configure the
vast majority of all use cases with
annotations and override them
with XML.
Although the whole EJB 1.0
idea was based on aspects, you
will find only two mentions of
the word aspect in the original
AOP was a hot
topic a few years
ago, but it never
really took off
in J2EE—and
for good reason.
specification in different contexts.
AOP and EJB 1.0 were “invented”
nearly at the same time.
In J2EE, the configurable decoration of an EJB bean with, for
example, transactions was just an
integral part of the development
experience. Other frameworks
provided the same functionality
but called that functionality AOP.
You will have a number of
aspects by defining a simple EJB
3. 1 bean. For example, a stateless
EJB 3. 1 bean comes with transaction and lifecycle aspects out of
the box.
The method call is processed by a
chain of default and configurable
aspects until it reaches the actual
business logic. Outside the application server, you would probably
implement the same functionality with the decorator pattern
or with a more generic solution,
such as AOP.
ABOUT US
@Stateless public class Greeter {
public String greet(){
}
}
blog
PHOTOGRAPH BY
THOMAS EINBERGER/
GETTY IMAGES
Aspects Are Commodities
The integral parts of the
Enterprise JavaBeans (EJB) 1.0
specification (JSR 318) in early
The method greet() is never
invoked directly. The container
dispatches the invocations to
free EJB instances from the pool.
Also, transactions are started
before each method invocation.
Generic Decorators:
Interceptors
Although the Greeter EJB bean is
injected directly into a Servlet, as
shown in Listing 1, you can still
decorate the call.
An interceptor is similar to
the Proxy class introduced with
JDK 1. 3, but it is easier to use. You
only have to implement a class
with a single method. Listing 2
shows a generic business
method interceptor.
Although the method name can
be freely chosen, the return type,
the exception, and the parameter have to match the signature
defined in Listing 2. An interceptor is associated with a given
