Second-generation aspect-oriented programming

Apply advice dynamically with the new crop of AOP frameworks

By Dave Schweisguth, JavaWorld.com, 07/05/04

Print
Email
Feedback
Resources
Discuss

Digg
Reddit
SlashDot
Stumble
del.icio.us
Technorati
dzone

Modularization 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 raise the bar again, 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 originally from 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 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!