Second-generation aspect-oriented programming (3)

转载 2004年10月20日 12:42:00
 

Second-generation aspect-oriented programming

Apply advice dynamically with the new crop of AOP frameworks

rule_ltblue.gif
Printer-friendly versionPrinter-friendly version | Send this article to a friendMail this to a friend


Page 3 of 3

Advertisement
?SIT=jw-BigBox&BA=1

Dynamic AOP with JBoss AOP
JBoss AOP is an AOP implementation developed by JBoss. While it came out of the desire to use AOP in the JBoss application server, it is an independent framework like AspectJ that can be used in any Java program. To see how it compares to AspectJ, let's jump right in to the same example recoded for AspectJ. We'll use all of the same code we used with the AspectJ example with a few exceptions. Here's what advice looks like in JBoss AOP:

public class ContextPasser implements Interceptor {
   public String getName() {
      return getClass().getName();
   }

   public Object invoke(Invocation invocation) throws Throwable {
      ServerSideContext.instance().setContext(
         ClientSideContext.instance().getContext());
      return invocation.invokeNext();
   }

}

JBoss AOP advice is simply a Java class that implements the interface org.jboss.aop.Interceptor. This interface has one trivial method: getName(), which is used for display, and one interesting method, invoke(Invocation), which is where we put the same context-passing code we put in the AspectJ advice. The last line of invoke(Invocation) returns control to the framework. Here it's just a bit of boilerplate, but in a different situation, we could replace the value returned from the actual method call with something else.

That's it! Advice is just a Java class in JBoss AOP, so there is no new syntax to learn and all of your development tools work with it like any other Java code. That takes care of the first objection we raised above.

But where's the equivalent to AspectJ's pointcut expression, which binds the advice to a method call? JBoss AOP provides two different ways to do this. The first uses a configuration file, usually called jboss-aop.xml:

<aop>
   <bind pointcut="execution(* *->@contextual(..))">
      <interceptor class="ContextPasser"/>
   </bind>
</aop>

This file is usually read at class load time, so we can add and remove advice and change the methods to which advice applies without recompiling. If we wish, we can compile our aspects instead, just as we did with AspectJ; this file will then be interpreted at compile time rather than at load time.

The other way to attach our advice is even more flexible. We still need a pointcut in jboss-aop.xml to tell JBoss AOP what methods we might want to advise:

<aop>
   <prepare expr="execution(* *->@contextual(..))"/>
</aop>

But this doesn't actually advise any classes, only prepares classes to be advised. (The need to prepare classes proves somewhat annoying, and it may disappear in a future version of the Java VM that has better support for runtime class redefinition.) Having prepared our class, we can advise it in our own code at any time:

public class ProxyFactory {
   private static final ProxyFactory INSTANCE = new ProxyFactory();

   public static ProxyFactory instance() {
      return INSTANCE;
   }

   public Object getProxy(String name) {
      Advised advised = (Advised) new ContextRetrieverImpl();
      advised._getInstanceAdvisor().insertInterceptor(new ContextPasser());
      return advised;
   }

}

In the AspectJ example, we didn't show ProxyFactory because it only constructed and returned an instance of ContextRetrieverImpl. Here we actually instantiate the advice and attach it to the instance we want to advise. With this method, we're completely free to use our advised objects in any context we like. We can have one instance that is advised and another that isn't, or we can add or subtract advice from a single instance as necessary.

I have yet to say anything about how we can free AOP from the issues associated with attaching advice to objects using matching expressions. Careful readers will have noticed that the matching expression used in jboss-aop.xml doesn't actually mention a class or method name. JBoss AOP does allow definition of pointcuts that refer to specific classes, methods, etc., just like AspectJ, but in this example, we chose not to do that. Instead, we use the notation @contextual, which refers to an annotation we placed on the method we want to advise. Here it is in ContextRetrieverImpl:

public class ContextRetrieverImpl implements ContextRetriever {
   /** @@contextual */
   public Object get(Object key) {
      return ServerSideContext.instance().get(key);
   }
}

A JBoss AOP annotation looks like a javadoc tag but with a double @ sign. JBoss AOP's AnnotationC tool parses Java source and compiles the annotations it finds into a file, usually called metadata-aop.xml. This gives us the most flexibility possible in attaching advice to our code: when AspectJ-style pointcuts do the job, we can use them, attaching our advice without editing the code being advised. If we need to advise a set of methods for which it's unreasonable to write a pointcut, we can either put annotations on the target methods as shown here, or (if modifying the code to be advised is not an option) we can write metadata-aop.xml ourselves.

If you've read about the features coming in J2SE 1.5 (aka Tiger), you might have noticed that JBoss AOP annotations behave much like J2SE 1.5 annotations (which are specified in JSR 175). In fact, JBoss AOP will support JSR 175 annotations when the final version of J2SE 1.5 becomes available, making its own annotation system unnecessary and removing the need for precompilation.

In software, as elsewhere, power and flexibility come at a price. The design tradeoffs that JBoss AOP makes are typical of those made in the new generation of AOP frameworks. Attaching advice at runtime breaks the separation between your code and the AOP framework. The clean separation of advice targeting from code semantics that annotation allows requires code changes, or the complexity of an additional layer of indirection, and so on. But the only good deal is the one that gets you what you need, and the intense effort that has been expended on the new frameworks makes it clear that these features are needed in the application server world.

The competition
JBoss AOP is given here as an example, but it isn't the only serious second-generation AOP framework out there. The following chart lists more AOP implementations for the Java platform and highlights their features.

AOP frameworks

Feature/issue AspectJ AspectWerkz JBoss AOP Spring dynaaop
Weaving time Compile/load-time Compile/load-time Compile/load/run Runtime Runtime
Transparency Transparent Transparent Choice Factory Factory
Per-instance aspects No No Yes Yes Yes
Constructor, field, throw, and cflow interception All All Some Some None
Annotations No Yes Yes Yes No
Standalone Yes Yes Yes No Yes
AOP Alliance No No No Yes Yes
Affiliation IBM BEA JBoss Spring ?

The frameworks are listed roughly in order of "heaviness," from AspectJ on the left—with its own language and supporting tools, rigid separation of aspects from Java code, and static compilation—to lighter-weight frameworks on the right, which do everything at runtime, albeit with more impact on client code. One can actually think of Java's dynamic proxies as a simple AOP framework; they'd be somewhere off to the right side of the table.

"Transparency" indicates whether a framework operates without requiring changes to client code ("transparent"), or whether it requires clients to obtain advised objects from factories ("factory"). JBoss AOP offers a choice of either technique. Frameworks with "per-instance aspects" can attach advice to selected instances of an advised class and not to others. This differs from the ability to associate a different set of aspect state with each advised instance, which AspectJ and AspectWerkz do offer. Note that using per-instance aspects requires using a factory.

"Constructor, field, throw and cflow interception" shows whether a framework can advise program constructs other than methods. Note that all of these frameworks also support introductions or mixins, an important AOP feature that I didn't demonstrate. Most AOP frameworks are standalone, even those associated with application servers. Only Spring's AOP framework is not, or at least is not available separately. The "AOP Alliance" is a common API for aspect-oriented programming implemented by some frameworks.

Finally, the table lists the application server vendors or developers with which most are associated. The IBM-founded Eclipse Foundation maintains AspectJ, and IBM is expected to add AspectJ support to WebSphere. The originally independent AspectWerkz project is now sponsored by BEA and supports BEA's proprietary JRockit virtual machine. JBoss AOP comes from JBoss and will be used extensively in JBoss 4.0.

This table isn't exhaustive. Many more AOP implementations and related projects are available, some going strong, some just announced, and some fading away. The Aspect-Oriented Software Development conference Website is one place to keep watch.

Where do we go from here?
With so many options for aspect-oriented programming, which one should you use? Different projects will find their best fits in different frameworks. More complex projects, especially those involving distributed, multiuser systems, will probably want the dynamic features of the newer frameworks. I hope that understanding the issues outlined in this article will make it easier for you to choose the right framework for your own projects.

Although most of these frameworks are really standalone, it seems likely that many organizations that come to AOP through application server development will choose the AOP framework allied with their application server. The future of AOP in the Java world may be the future of the application server market. It's too early to tell whether the AOP Alliance or some other standards effort will allow developers to move between frameworks with ease, but it seems unlikely given the diversity in approaches among the different frameworks.

And will AOP ever take hold outside of middleware? Most likely. Most developers will work on AOP-enabled middleware without ever worrying about AOP most of the time. But every project needs to open the hood every now and then, and, having seen what AOP can do in middleware, more and more of us are likely to use it elsewhere in our own software systems. The growing ubiquity of middleware just may be AOP's big break. jw-dingbat.gif


Page 1 Second-generation aspect-oriented programming
Page 2 An AOP wish list
Page 3 Dynamic AOP with JBoss AOP

Join the discussion about this article Click Here To Add Your Comment
. .Weak treatment of an important topic Anonymous   07/05/04 10:13 AM
..sociology of AOP Pedoro   09/01/04 03:25 PM
..Re: Weak treatment of an important topic Anonymous   08/04/04 10:31 AM
..Re: Weak treatment of an important topic Anonymous   07/07/04 12:45 AM
..Re: Weak treatment of an important topic Anonymous   07/09/04 12:36 PM
..can you define what "some" means? Bill Burke   07/08/04 08:02 AM
..Re: can you define what "some" means? Anonymous   07/09/04 12:46 PM
..Annotations and JBoss AOP Bill Burke   07/08/04 07:58 AM
..The original problem? mdaffin   07/07/04 05:54 AM
..Second-generation aspect-oriented programming JavaWorldAdministrator   07/04/04 10:33 AM
..Re: Second-generation aspect-oriented programming JDelfosse   07/05/04 02:54 AM

Printer-friendly versionPrinter-friendly version | Send this article to a friendMail this to a friend

About the author
Dave Schweisguth has written software in the biotechnology industry since 1996 and has used Java since 1997. Presently he's a software architect at Applied Biosystems in Foster City, Calif., where he contributes to and evangelizes the company's next-generation service-oriented software architecture.

Resources
Download the source code that accompanies this article:
http://www.javaworld.com/javaworld/jw-07-2004/aop/jw-0705-aop.zip
AspectJ:
http://eclipse.org/aspectj/
"I Want My AOP!" Ramnivas Laddad (JavaWorld): The Service Locator pattern:
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html
"Use Your Singletons Wisely," J.B. Rainsberger (developerWorks, July 1, 2001):
http://www-106.ibm.com/developerworks/webservices/library/co-single.html
TheServerSide.com's report on the EJB 3.0 announcement:
http://www.theserverside.com/news/thread.tss?thread_id=25779
JBoss AOP:
http://www.jboss.org/developers/projects/jboss/aop
JSR 176, J2SE 1.5 (Tiger) Release Contents:
http://jcp.org/en/jsr/detail?id=176
JSR 175, A Metadata Facility for the Java Programming Language:
http://jcp.org/en/jsr/detail?id=175
JBoss 4.0:
http://jboss.org/products/jbossas4
Spring:
http://www.springframework.org
PicoContainer:
http://www.picocontainer.org/
HiveMind:
http://jakarta.apache.org/hivemind/
The Beehive project:
http://dev2dev.bea.com/technologies/beehive/index.jsp
AspectWerkz:
http://aspectwerkz.codehaus.org/
dynaop:
https://dynaop.dev.java.net/ Aspect-Oriented Software Development conference technology lists:
http://aosd.net/technology/
"Meet the New JBoss," Rick Grehan, InfoWorld Test Center (JavaWorld, August 2003):
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-iw-jboss.html
The Object-Oriented Design and Programming section of JavaWorld's Topical Index features numerous articles addressing design:
http://www.javaworld.com/channel_content/jw-oop-index.shtml
Also by Dave Schweisguth: "Java Tip 134: When Catching Exceptions, Don't Cast Your Net Too Wide" (JavaWorld, February 2003):
http://www.javaworld.com/javaworld/javatips/jw-javatip134.html

Second-generation aspect-oriented programming (2)

  Second-generation aspect-oriented programming Apply advice dynamically with the new crop of AOP fr...
  • jgo
  • jgo
  • 2004年10月20日 12:40
  • 802

Second-generation aspect-oriented programming (1)

  Second-generation aspect-oriented programming Apply advice dynamically with the new crop of AOP fr...
  • jgo
  • jgo
  • 2004年10月20日 12:36
  • 1045

Aspect-oriented programming

我们对面向过程和面向对象的编程语言已经耳熟能详了。 今天来看看Aspect-oriented programming,也就是面向行为的编程。 参考wiki,写的很不错: http://en....
  • OnlyQi
  • OnlyQi
  • 2011年12月31日 12:46
  • 2419

AOP( aspect-oriented programming)面向切面编程

AOP( aspect-oriented programming)面向切面编程 一、什么是AOP? 可以通过预编译方式和运行期动态代理实现在不修改源代码情况下给程序动态统一添加功能的一种技术。 ...
  • ly969434341
  • ly969434341
  • 2016年08月27日 19:45
  • 367

Second-generation aspect-oriented programming By Dave Schweisguth

Dynamic AOP with JBoss AOP JBoss AOP is an AOP implementation developed by JBoss. While it came out ...
  • WonderOne
  • WonderOne
  • 2004年12月21日 12:59
  • 1230

AOP(面向切面编程 Aspect Oriented Programming)

AOP(面向切面编程 Aspect Oriented Programming)概念(百度百科) 通过 预编译方式和运行期动态代理 实现 程序功能 的 统一维护 的一种技术。特点:低耦合,高聚合。 A...
  • daisywangyy
  • daisywangyy
  • 2016年06月12日 10:01
  • 866

Java 面向切面编程(Aspect Oriented Programming,AOP)

本文内容 实例 引入原始方法装饰者模式 JDK 动态代理和 cglib 代理直接使用 AOP 框架——AspectWerkz 新公司使用了 AOP 相关的技术,于是复习一下,没怎么...
  • wah001
  • wah001
  • 2017年07月09日 09:51
  • 130

AOP-面向切面的编程

课程概要: AOP的简介AOP的示例AOP的术语AOP的实现者 一.AOP的简介 1.AOP的基本概念 AOP即Aspect-Oriented programming的缩写,中文意思是面向...
  • icarus_wang
  • icarus_wang
  • 2016年06月15日 18:33
  • 460

AspectC++

About the Project The success of Aspect-Oriented Software Development rises and falls with user-fri...
  • gxp
  • gxp
  • 2012年03月13日 14:59
  • 708

AOP面向切面编程(Aspect Oriented Programming)

AOP为Aspect Oriented Programming的缩写,意为:面向切面编程,通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。AOP是OOP的延续,是软件开发中的一个热点,...
  • sidihuo
  • sidihuo
  • 2016年02月29日 13:50
  • 325
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Second-generation aspect-oriented programming (3)
举报原因:
原因补充:

(最多只允许输入30个字)