Second-generation aspect-oriented
programming
Tutorial Details:
Second-generation aspect-oriented programming
Second-generation aspect-oriented programming
By: By Dave Schweisguth
Apply advice dynamically with the new crop of AOP frameworks
odularization makes programming possible. Throughout the history of computing, a parade of organizational devices?the high-level language, the subroutine, the object?has allowed us to write increasingly more expressive and powerful code. But, just as with computer hardware, when our abilities improve, we just raise the bar, and here in the twenty-first century, we still struggle to quickly and cheaply produce large programs. What is the next step, the new way to structure our programs that will take our abilities to the next level?
Aspect-oriented programming (AOP) is one attempt at an answer. Conceived at Xerox PARC (an auspicious pedigree!) in the late 1990s, AOP intends to modularize cross-cutting concerns : lines of code that would have to be repeated throughout an ordinary program. AOP gathers all of these cross-cutting concerns into a single place, an AOP construct similar to a class, known as advice .
AspectJ, also originated at Xerox PARC and now developed by the Eclipse Foundation, is an implementation of AOP for the Java platform. It is a mature and solid framework that has gone through several significant releases and is even supported by some third-party tools. Recently, however, application server designers have realized that while?just as AOP proponents have been saying for years?AOP seems a natural way to implement many kinds of application server functionality such as remoting, persistence and transactions, AOP would be much easier to use in the dynamic environment of the Java platform if its implementation were equally dynamic.
For a thorough introduction to AOP concepts and the AspectJ implementation, see Ramnivas Laddad's three-part JavaWorld series, " I Want My AOP!" . For this discussion, I assume you're up to speed on AOP basics and briefly present classic AOP examples so we can get on to the new stuff.
Old-school AOP with AspectJ
Here's an example of how aspect-oriented programming might be used in a middleware framework: Imagine that in our framework, a client accesses services via proxies. The services might be in another VM and might be reached by any remoting technology; hiding these things from the client is the framework's reason for being. One of our framework's features is its ability to propagate any context that a developer wishes from the client to the services it calls, transparently to the client. For example, an application might log a user into a security service and put an authentication token in the context. From then on, any services called by that application would be able to retrieve the authentication token from the context?on the server side?and use it to control the authenticated functionality to which the client has access.
First, let's write a simple test to show that context is propagated:
public class ContextPassingTest extends TestCase {
public void test() {
ClientSideContext.instance().put("userID", "dave");
ContextRetriever proxy = (ContextRetriever)
ProxyFactory.instance().getProxy("ContextRetriever");
assertEquals("dave", proxy.get("userID"));
}
}
In our test, we first put an authentication token into the context. Next, we get a proxy to our service from a singleton ProxyFactory . (This is an example of the Service Locator pattern , in which a Factory hides from the client the complexity of constructing a proxy to a remote service.) The service, an instance of ContextRetriever , simply returns the requested value from its context. In the test's last line, we ask for our authentication token back and test to see whether it has the value it should. That's it!
As with any nice compact example, a couple of comments are in order. First, note that while this test may seem rather pointless, in a real application, we read from the context in a place different from where we wrote to it, and we actually use context information on the server-side instead of just sending it back.
Second, note that although this example uses the Singleton pattern in several places because it is well known and succinct, if you ever find yourself writing a widely used framework, you should certainly not use the Singleton pattern in its API. Singleton requires the singleton instance to be a concrete class, whereas interesting classes should always be hidden behind interfaces to allow the implementations to be swapped without affecting clients. Furthermore, since the singleton reference is global, it proves difficult to make an object use a different instance when necessary, such as in testing. (See " Use Your Singletons Wisely " for more on this topic.) Having warned you about the Singleton pattern, we return to using it for brevity, but don't take it to heart.
Now let's look at the classes our test uses. ClientSideContext is simply a singleton wrapper around a HashMap , a place to store context until it's needed:
public class ClientSideContext {
private static final ClientSideContext INSTANCE = new ClientSideContext();
public static ClientSideContext instance() {
return INSTANCE;
}
private final Map mContext = new HashMap();
public void put(Object key, Object value) {
mContext.put(key, value);
}
public Map getContext() {
return mContext;
}
}
The ContextRetriever interface (not shown; see Resources for complete source code) has a single method, get(Object) . In this simple example, ProxyFactory (also not shown) just creates and returns an instance of the following ContextRetriever implementation:
public class ContextRetrieverImpl implements ContextRetriever {
public Object get(Object key) {
return ServerSideContext.instance().get(key);
}
}
ContextRetrieverImpl delegates to a singleton instance of ServerSideContext , which is similar to ClientSideContext but is used on the server side:
public class ServerSideContext {
private static final ServerSideContext INSTANCE = new ServerSideContext();
public static ServerSideContext instance() {
return INSTANCE;
}
private final Map mContext = new HashMap();
public void setContext(Map context) {
mContext.putAll(context);
}
public Object get(Object key) {
return mContext.get(key);
}
}
So, how does the context get from client to server? With the following aspect :
aspect ContextPasser {
before(): execution(* ContextRetrieverImpl.*(..)) {
ServerSideContext.instance().setContext(
ClientSideContext.instance().getContext());
}
}
This aspect contains a single piece of advice . The advice is before() advice, which runs before the method being advised. The execution() statement determines the methods before which the advice runs. In this case, the expression ContextRetrieverImpl.*(..) , referred to as a pointcut , causes the advice to run before any method of the class ContextRetrieverImpl . In the advice's body, where the actual work is done, we finally see how our context is passed: the entire context is copied from ClientSideContext to ServerSideContext . In a real framework, of course, the server side might be in another VM and we'd have a bit more work to do, but our short version illustrates the point.
Writing our context-passing functionality in an aspect gives us some nice advantages over a conventional object-oriented design. It reduces the dependencies from the client and server sides to the context-related classes, without requiring the service to implement an interface (as an EJB (Enterprise JavaBean) component must do to receive a SessionContext ). We've actually decoupled context passing from the rest of the framework; so, if for some reason we don't need context passing?perhaps in some applications we intend to use only services that don't need context?we can recompile the application without the ContextPasser aspect. The test above will fail, but everything will compile and code that doesn't require context to be passed will work just fine without the overhead of passing unused context. This is exactly the sort of modularization that AOP was intended to provide. And we don't need to stop here: security enforcement code and even the proxying itself can be moved into aspects as well.
An AOP wish list
As powerful as the AspectJ implementation of AOP is, a demanding developer can always find something new to demand. The most obvious is right in front of us: aspects aren't written in Java. That means learning not just a new design, but also new language syntax?and not only does the developer need to understand the AspectJ language, so do the tools that he or she uses. An all-Java way of writing aspects would be welcome.
The way AspectJ ties advice to methods?writing a pointcut expression that matches the names of the methods to be advised?changes the meaning of traditional Java programs in another way. In ordinary Java, a method name is simply an identifier. Far more important than any comment, a well-chosen name is the best way of making a method's purpose obvious to a reader. But in AspectJ, method names (and class, constructor, and field names?although I've given only an example of advising a method, AspectJ can also attach advice to other program constructs) have two purposes: as well as communicating, they must also serve as targets of matching expressions. Changing a method name in a program that includes aspects can cause the method to not be advised when it should be, or to be advised when it shouldn't. Adding and removing methods can cause unexpected effects with aspects as well. Some tools address these issues with AspectJ, but aspects aren't making our life as simple as we had hoped. And even if we manage to keep all of our pointcuts synchronized with our identifiers, we may be tempted to change our identifiers to match existing pointcuts or allow us to write shorter pointcuts, which might compromise our program's readability. Is there another way?
A different issue arises when considering more c
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Second-generation aspect-oriented
programming
View Tutorial: Second-generation aspect-oriented
programming
Related
Tutorials:
 Java decompilers
compared - JavaWorld - July
1997
Java decompilers
compared - JavaWorld - July
1997
|
I want my AOP!, Part 1
I want my AOP!, Part 1
|
I want my AOP!,
Part 2
I want my AOP!,
Part 2
|
I want my AOP!, Part 3
I want my AOP!, Part 3
|
Use AOP to maintain legacy Java applications
Use AOP to maintain legacy Java applications
This artical shows you how to use aspect-oriented programming (AOP) to gain an unprecedented view into the inner workings of even the most opaque of legacy applications.
Please note that this article assume
|
Improve Application Management With JMX
Improve Application Management With JMX
Leverage JMX technology and existing tools to boost the operations management capabilities of your business applications.
|
Object-relation mapping without the container
If you follow the latest developer buzz then you\\\\\'ve likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming).
|
Ganymede
A log4j plugin to Eclipse that works similar to chainsaw (SocketServer). Includes color, filtering, detailed information, and saves settings.
|
Declarative Programming in Java
Declarative Programming in Java
What makes EJB components special is the declarative programming model through which we can specify the services such as security, persistence, transaction etc., that the container should provide. An EJB only implements
|
Performance Analysis of J2EE Applications Using AOP Techniques
Performance Analysis of J2EE Applications Using AOP Techniques
In this article we demonstrate the use of AOP techniques through which J2EE applications can be easily instrumented without any modifications to application code. We have developed a very sim
|
Second-generation aspect-oriented
programming
Second-generation aspect-oriented
programming
|
JDBC scripting, Part 2
JDBC scripting, Part 2
Programming and Java scripting in JudoScript
Summary
JudoScript is a rich functional scripting language, and an easy and powerful general programming and Java scripting language.
JudoScript's power comes from its synergy of
|
Aspect-Oriented Annotations
Aspect-Oriented Annotations
Annotations are one of the new language features in J2SE 5.0, and allow you to attach metadata onto any Java construct. Meanwhile, Aspect-Oriented Programming (AOP) is a fairly new technology that makes it easier for you to en
|
Aspect-Oriented Programming in Java
This article is divided into three parts: The first part explaines the concepts of AOP, the second introduces AspectJ(TM), an implementation of the AOP concepts in Java, and part three compares the AOP approach to metalevel programming.
|
Prova
Prova: A Language for Rule Based Java Scripting, Information Integration, and Agent Programming
|
Develop aspect-oriented Java applications with Eclipse and AJDT
AspectJ is an aspect-oriented extension of the Javaâ„¢ language that enables a modular implementation of crosscutting concerns. This crosscutting behavior, which can be static or dynamic, presents an extra challenge to tools that support AspectJ. The AJDT
|
Servlet Essentials
This document explains the concepts of Java Servlets and provides a step-by-step tutorial for writing HTTP Servlets with complete source code for the example Servlets. The tutorial and the other chapters cover all facets of Servlet programming from a ...
|
Introduction to Servlets, JSP, and Servlet Engines
Servlets are the Java Technologies' answer to CGI programming. They are programs which run on the server side and generate dynamic content. Why would one prefer to use Servlets over traditional CGI programming?
|
Programming Jakarta Struts: Using Tiles, Part 2
In part two in this series of book excerpts on using tiles from Programming Jakarta Struts, learn how to install and configure tiles, as well as get an overview on tiles.
|
Asking "Why" at Sun Laboratories: A Conversation with Director, Glenn Edens
Sun Laboratories Director, Glenn Edens, discusses new research developments in the Java language and the gratifications and trials of running a research lab.
|
|
|
|
