1、AOP 工具比较AOP 工具比较AOP 技术的时代已经来临，但是怎样才能为项目选择正确的工具呢？在新推出的AOPWork系列的第一篇文章中，面向方面（aspect-oriented）的编程专家 Mik Kersten 将比较 4 个领先的 AOP 工具（AspectJ、AspectWerkz、JBoss AOP 和 Spring AOP），帮助大家判断应该选择哪一个工具。本文由两个部分组成，在文中，作者将重点介绍这些工具的语言机制和不同技术的优劣。他分别用 4 种工具编写同一个示例，让读者感觉到它们之间的高级区别。他还将讨论每种工具的语法技术对 AOP 语义产生的效果。在文章结束时，作者将对工
2、具的核心语言机制（例如切入点匹配和组合、通知的格式、连接点上下文）进行深入比较。注意，本文将解释最近宣布的 AspectJ 和 AspectWerkz 项目合并的意义。面向方面编程（AOP）在 Java 平台上变得日益流行。随着 AOP 出版物和会议的增加，这项技术的工具与实现越来越多。虽然人们很清楚 AOP 是面向对象技术的补充，但是 Java 开发人员该如何评估当前的 AOP 工具，特别是每项新技术实现的优劣，这方面则相对不那么清楚。本文有两部分，而且本文还是 developerWorks 上一个新的 AOP 系列的第一篇文章。在本文中，将概述 AOP 工具当前的技术状况，比较对于该技术而
3、言最成熟的一些方法：AspectJ、AspectWerkz、JBoss AOP、和 Spring AOP，并对比与每种方法的采用有关的问题。文中还会解释最近宣布的 AspectJ 和 AspectWerkz 项目合并的意义（请参阅参考资料）。本文无意作为 AOP 的介绍或某个特定 AOP 实现的入门读物。而是将对目前使用最普遍的 AOP 技术进行概述。对每个工具的语言机制和工具支持的内在优劣进行探讨，将有助于为项目选择最合适的技术。这里定义的指标还会让读者更加容易地评估即将推出的 AOP 工具和特性。关于 developerWorks 上介绍 AOP 的最新文章列表，请参阅参考资料。请注意本文
4、有两个部分，为了方便读者，两部分同时发布。第 1 部分侧重于这 4 个领先工具各自的 AOP 语言机制处理技术，其中包括工具的方面语法（aspect syntax）和切入点的表示、用来声明方面的机制范围等主题。第 2 部分继续深入介绍领先的 AOP 实现如何与现有的开发环境、工具和库进行集成。这一部分包括以下主题：方面设计器、IDE 插件、可伸缩性和 AOP 工具将来的发展方向，还包括对最近 AspectJ 和 AspectWerkz 项目合并的关注。选择成熟的工具AOP 是一项新技术，所以，并不是现有的所有工具都已经成熟到适用于商业开发。判断成熟度的一个主要因素是用户的采用程度。在考虑把一项
5、新编程技术应用到商用之前，这项技术必须从活跃的用户社区的反馈中得到强化。表 1 显示了 上列出的目前可以使用的 AOP 工具（请参阅参考资料）。每个工具的用户列表贴子数量可以表明它的用户基数（省略了贴子的实际数量，因为单独一个月的统计可能给读者造成误解）。表 1. 在 2004 年 11 月 AOP 工具用户列表中的贴子数量关于这个系列AOPWork系列面对的是在面向方面编程上有些基础，同时想扩展或加深这方面了解的开发人员。同 developerWorks 的大多数文章一样，这个系列非常实用：读完每篇介绍新技术的文章，都可以立即将其投入使用。为这个系列选择的每个作者都是面向方面编程领域的领导或
6、专家。许多作者都是系列文章中介绍的项目和工具的参与者。每篇文章都力图提供一个中立的评述，以确保这里表达的观点的公正与正确。请就文章的评论或问题分别与这些文章的作者联系。要对这个系列整体进行评论，可以与这个系列的负责人Nicholas Lesiecki联系。关于本文本文并不想突出某一个工具，而是要用一种批判的、没有偏见的方式突出每个工具的优势与不足。虽然作者是 AspectJ 项目的参与者之一，但是在编写本文的时候，也咨询了其他 AOP 工具项目的领导人，以确保公平地展示所讨论的技术。请注意 Spring 的 AOP 部分没有形成一个独立的下载或用户社团，所以用户基数相当比例的用户可能没有给 S
7、pring AOP 发贴，而是投在别的主题上了。在 上还列出了 4 个额外的工具，但是它们要么缺乏用户讨论论坛，要么在 11 月没有贴子。AOP 工具虽然没有列在表中前四位，但它在技术上可能非常成熟，可是缺乏较大的用户基数就意味着它们还没有经受过采纳程度测试。虽然在本文编写的时候，它们还不适合于商业开发，但是这些工具的日后发展还是值得关注的。通过上表的比较，还可以看出非 Java 平台的 AOP 工具没有 Java 平台的工具成熟，但是应当注意 .NET 和 C+ 工具的用户社区正在成长。根据表 1，可以看出，从用户采用度的角度来说，AspectJ、AspectWerkz、JBoss AOP
8、和 Spring AOP 是领先的工具。所有这些工具都是适合用于商业开发中的开源项目。按字母顺序将它们排列如下，包括它们 V1.0 版本的发布日期： AspectJ 2001 年由 Xerox PARC 的 AOP 小组发行。目前主页在 eclipse.org 上，由 IBM 支持。版本已经更新到 1.2.1。 AspectWerkz 2002 年发布，由 BEA Systems 支持。版本更新到 2.0RC2。 JBoss AOP 2004 年作为 JBoss 应用程序服务器框架的扩展发布。版本更新到 1.0。 Spring AOP 2004 年作为 Spring 框架的扩展发布。版本更新到
9、 1.1.3.都是为了连接点本文介绍的每个 AOP 工具都采用了连接点（join point）模型和机制，显式地声明程序的横切结构。虽然各个工具实现这个框架的技术非常相似，但是理解底层机制对于了解每项技术的优劣是非常重要的。在这一节中，将回顾 AOP 的连接点模型以及利用连接点模型的语言模型。支持机制AOP 工具的设计目标是把横切的问题（例如认证和事务管理）模块化。在单独使用面向对象技术实现的的时候，处理这些问题的代码会分散在整个系统中，这种分散造成管理和发展横切结构时出现不必要的困难。与对象提供了一种能够清楚地捕获继承结构的语言机制类似，AOP 也为横切问题的良好模块化提供了同样的好处。位于
10、每个 AOP 工具核心的是连接点模型，它提供了一种机制，可以识别出在哪里发生了横切。连接点就是主程序和方面相遇的地方。静态连接点允许方面定义类上的新成员。动态连接点是方面执行与程序执行相遇的地方。例如，普通的 Java 程序执行方法调用、字段设置这样的连接点。再比如说，请考虑一下这样一个问题：对改变Account状态的活动进行监视，就像在 Ramnivas Laddad 的AspectJ in Action一书中讨论的那样（请参阅参考资料）。 图 1 中的顺序图突出了在Account操作上形成的一些动态连接点。图 1. 突出了选中的动态连接点的 UML 序列图下面的编号与图中的编号对应：1.
11、方法执行连接点，与方法返回之前的生命周期对应。2. 控制流程捕捉在控制流程序列中出现的各个连接点；在这个例子中， 在debit()方法调用下方的序列描述了在debit()调用中发生的全部连接点。3. 字段访问连接点对应着字段的读和写；在这个例子中，在Account类上对name字段进行了赋值。AspectJ 和 AspectWerkz 项目合并AOP 技术正在迅速地向前发展，在本文的第 2 部分突出了领先的 AOP 工具的预计的发布计划。有一个那些思想超前的读者会特别感兴趣的主题，这就是最近 AspectJ 与 AspectWerkz 项目的合并，这一合并会给 AOP 的发展前景带来重大的变化
12、。一些开发人员在这些项目上进行合作，生产 AspectJ 5，这是一种单一工具，融合了这里介绍的 AspectJ 和 AspectWerkz 的语法。重要的是要注意 AspectWerkz 并没有正在消失。它将成为编写 AspectJ 程序的另一种方法，并更名为AspectJ 风格。在这里可以看到，语法是 AOP 实现之间的主要区别因素，而核心的 AOP 机制通常非常相似。 AspectWerkz 和 AspectJ 的相似性使得这两种技术可以联合。合并可以在提供方面语法的时候提供更多的灵活性，同时保留着关键的好处（例如静态类型化和成熟的工具支持）。有关合并的细节以及相关文档，可以从参考资料中
13、得到。虽然本文重点放在立刻就可以开始使用的工具上，但是这里概述的指标和优劣也适用于未来的发行版（例如 AspectJ 5）。切入点、通知和类型间声明AOP 工具提供了识别连接点集合的机制，叫作切入点（pointcut）。通知（advice）机制指定在程序执行过程中遇到匹配的切入点时应当采取什么行动。另外，类型间声明（inter-type declaration）（开放类或混合类提供了在现有类型上声明额外成员的方法。切入点、通知和类型间声明组合在一起，使 AOP 语言可以清楚地表达横切问题。方面声明可以在标准的 Java 字段和方法之外包含这三类成员。方面代表一套模块化良好的横切结构。如下所示，
14、不同的 AOP 技术实现这些方法的技术各不相同。但是，每种技术的核心，都是连接点的访问、编辑、命名和抽象机制。切入点可以通过显式枚举方式描述连接点集合。应当用一个示例指定图 1所示的Account的利息的三个方法调用。虽然枚举可能很有用，但是用结构化属性的方式表示连接点通常更方便。这类基于属性的切入点可以表示一套与“每个针对Account子类型的调用”匹配的连接点，却不必强迫程序员枚举这些子类型。这样做可以保证向系统添加由Account扩展的新类时，新类会自动与切入点匹配。切入点支持复合（composition），这就允许把简单的 切入点组合成更复杂的切入点。例如，可以把所有Account调用
15、的切入点限制在那些针对特定类或控制流程进行的调用中。切入点的命名（naming）机制提高了可读性和复合性。对抽象（abstraction）与具体化（concretization）的支持，可以更加容易地创建通用库，对于要应用库的特定应用程序的切入点来说，这些库可以独立定义。最后，对切入点中公开连接点状态的支持允许对诸如正在执行对象和方法参数之类的访问事项进行商量。方面比较如前所述，所有 AOP 工具的底层机制都是连接点和切入点、通知和类型间声明的概念。在这些工具中，可以注意到的主要区别就是方面声明编写及应用到系统上的方式。这些工具可用以下方法中的一种进行方面声明：使用类似 Java 的代码、注释
16、或 XML。对于某些开发人员来说，熟悉用 Java 语言编程方面的知识，要比熟悉语言扩展技术的优劣更重要，这些内容会在后面的小节中讨论。对于其他人来说，了解注释和 XML 技术在集成上的优势，要比痛苦地把切入点当作字符串来操作更重要。在这一节中，将使用一个常见的示例指出每个工具在方面声明技术上的差异。请考虑图 1所示的Account类的授权策略这样一个示例。在面向对象的实现中，最常见到的，就是对认证的调用分散在Account类的众多方法以及需要认证的其他类中。在 AOP 实现中，可以明确地用一个方面捕获这个行为，而不必修改操纵帐户的代码。不管使用什么工具声明，这个方面都需要具备以下特征： 一个
17、切入点，捕捉banking.Account类上所有公共方法的执行。 一种引用正在认证的Account的方式。 通知，在切入点指定的连接点上调用Account的认证。现在，请看这几个领先的 AOP 工具各自是如何处理这个方面的。AspectJAspect 中的方面声明类似于 Java 语言中的类声明，如图 2 所示。由于 AspectJ 是 Java 语言语法和语义的扩展，所以它提供了自己的一套处理方面的关键字。除了包含字段和方法之外，AspectJ 的方面声明还包含切入点和通知成员。示例中的切入点使用了修饰符（modifier）和通配符（wildcard）模式来表达“所有公共方法”。对帐户的访
18、问，由pointcut参数提供。通知使用这个参数，而切入点则用this(account)把它绑定。这样做的效果，就是捕获了正在执行的方法所隶属Account对象。否则，通知的主体与方法的主体相似。通知可以包含认证代码，或者就像在这个示例中一样，可以调用其他方法。图 2. AspectJ 的方面构建 AspectJ 程序与构建 Java 程序类似，其中包括调用 AspectJ 的递增编译器，构建所有的项目源文件，包括普通的 Java 源文件。运行 AspectJ 程序也与运行 Java 程序一样，请注意要把aspectjrt.jar库添加到类路径中。要对在系统中应用哪个方面进行配置，必须把它们加
19、入包含列表或从中删除，包含列表会传递给编译器，可以通过 IDE 支持传递包含列表，如果正在 Ant 环境或命令行进行工作，也可以通过“.lst” 包含文件传递。注意，在第 2 部分中，将讨论构建 AOP 程序的细节以及方面设计的概念。AspectWerkzAspectWerkz 和 AspectJ 之间的重要区别就是：Authentication现在是一个普通的 Java 类，而不是一个方面。AspectWerkz、JBoss AOP 和 Spring AOP 都在没有改变 Java 语言语法的情况下加入了方面语义。AspectWerkz 提供了两种进行 AOP 声明的途径。最常用的是注释，注
20、释可以采用图 3 中的 Java V5.0 风格，也可以为了与 J2SE V1.4 兼容采用 Javadoc 风格。AspectWerkz 还支持另外一种基于 XML 的方面声明风格。XML 风格与下面介绍的 JBoss AOP 的风格类似，把方面声明放在单独的 XML 文件中。请注意通知就是普通的方法声明。按照约定，它被当作不同类型的方法声明，因为不应当显式地调用它，而是应该在满足特定切入点时自动运行它。AspectWerkz 的切入点声明是附加到切入点“方法”的字符串值，也可以在 XML 文件中独立存在。所以，没有切入点的import机制，所有的类型引用必须完全规范。对正在运行的Accou
21、nt对象的访问技术与 AspectJ 相同。请注意，规划的AspectJ语法看起来与 AspectWerkz 注释的语法非常相似。图 3. AspectWerkz 的方面构建 AspectWerkz 程序会涉及一个标准的 Java 构建，然后会涉及到后处理。要运行 AspectWerkz 程序，必须把 AspectWerkz 库放在类路径中。在使用不可插入的方面的情况下，由 aop.xml 文件配置系统中一些方面的包含情况。JBoss AOPJBoss AOP 基于 XML 的方面来声明风格，如图 4 所示。JBoss 也支持与图 3 所示相似的注释风格。在 XML 风格中，方面、切入点和通知
22、声明都以 XML 形式表示的。通知的实现，用的是普通的 Java 方法，由 JBoss AOP 框架调用。切入点和切入点到通知的绑定都在方面中用 XML 注释声明。JBoss 没有显式地绑定Account参数，而是提供了对当前正在执行的对象的反射访问，因此需要把类型转换到对应的类型。注意，即将发布的 JBoss 会提供一些静态类型的切入点参数来解决这一问题。图 4. JBoss AOP 的方面用 JBoss 构建方面只包括普通的 Java 构建。JBoss AOP 的运行时截取框架（interception framework）负责管理切入点匹配和通知调用。需要对启动和类路径做一些配置，但是
23、JBoss AOP 的 IDE 插件替用户做了这些工作。方面在 jboss-aop.xml 文件中配置。Spring AOP查看图 5 中的 Spring AOP 示例时，可以注意到其中的 XML 比前面介绍的技术多。与 JBoss AOP 类似，Spring 的通知实现是带有特殊参数的 Java 方法，由 Spring 框架调用。XML 描述accountBean，Spring 框架通过它访问Account对象，包括通知使用的拦截器advisor及其匹配模式，还有应用到模式的向前（before）通知。图 5. Spring AOP 的方面Spring AOP 的技术虽然提供了更加精细的配置，
24、但在将它用于 XML 时，它与 JBoss AOP 非常类似。构建、运行和配置 Spring AOP 方面的过程与 JBoss AOP 相同，但 Spring AOP 依赖的是 Spring 框架方便的、最小化的运行时配置，所以不需要独立的启动器。请注意，使用这个技术，只能通知从 Spring 框架检索出的对象。语法差异正如上面的图所展示的，AOP 工具之间的关键差异就是处理方面声明的方式。AspectJ 是 Java 语言的扩展，用它可以完全在代码中对方面进行声明。AspectWerkz 和 JBoss AOP 支持用方面元数据对 Java 代码进行注释，或者在独立的 XML 文件中对方面进
25、行声明。在 Spring AOP 中，则完全用 XML 对方面进行声明。所以，在三种不同的技术中，对方面进行编程的感觉可能非常不同。用 AspectJ 的代码风格，方面和切入点声明感觉起来就像 Java 代码。而用 JBoss AOP 或 AspectWerkz 的注释风格，感觉起来就像在现有 Java 元素上做的附加标签。而用 Spring AOP 风格，以及 AspectWerkz 和 JBoss AOP 的XML 风格时，感觉就像使用独立的声明性 XML 语言。每种技术都有它的优势，具体要由使用者决定哪个更适合需求。所以在这一节，将简要地讨论一些能够有助于进行决策的要点。自己的风格是什么
26、？不管选择哪个 AOP 工具，使用通知主体时只涉及到使用 Java 代码。如果需要修改切入点，那么区别是非常透明的。在使用 XML 风格时（就像在 Spring AOP 中），修改切入点包括：从通知找到 XML 文件中对应的切入点声明。从正面来说，这项技术把切入点和方面配置的工作全都局限于本地，但是如果要编辑许多通知和切入点，而且要在 Java 和 XML 之间重复地翻来覆去，那么这项工作就会变得很繁琐。如果使用 AspectWerkz 或 JBoss AOP 提供的注释风格，那么就可以把切入点的表达值从 XML 转移到 Java 成员的注释。这样可以更容易地并发处理通知体和切入点。如果选择了
27、 AspectJ 的代码风格，那么就会发现处理切入点感觉就像处理代码，而不像是处理非结构化的字符串值。从 Java 代码能得到的一切（例如“import”语句），都可以用于切入点。对比之下，如果用 AspectWerkz、JBoss AOP 和 Spring AOP 的 XML 和注释风格，总是需要在规范切入点中的类型引用。简洁还是繁琐？方面声明的风格对每个工具中使用的方面有很大的影响。例如，支持在 XML 中声明方面的工具，也支持在同一 XML 文件中对方面应用到系统的方式进行配置。在前面的小节中，只展示了切入点和方面声明，但是类型间声明同样受到风格选择的影响。在 AspectJ 中，类型间
28、方法声明看起来就像正常的方法声明，引用的技术也一样。而在其他技术中，则要指定一个类，扩展额外的混合类并继承那些额外的成员，通过注释或 XML 添加新方法。注意，目前 AspectJ 是惟一提供使用切入点的静态强制机制的工具。表 2 比较了这些工具对 AOP 语法的关键元素的处理技术。表 2. 比较领先的 AOP 工具中的语法显然，从图 2-5 的方面声明来看，代码风格是处理 AOP 声明最简洁的技术。它不需要对通知命名，也不需要显式地调用通知。代码风格不需要显式地把通知绑定到切入点（就像 XML 风格那样），也不需要把通知绑定到return语句（这是 AspectWerkz 的切入点“方法”所
29、需要的）。对于可以在图 3和图 4的 XML 中看到的复杂设计，AspectJ 对 Java 语言进行的语法扩展允许直接表示这些设计。用 AspectJ 编写方面，感觉起来更像是编写 Java 代码，避免了冗余的键入，因此出错也就更少。从不好的一面来说，Java 的语法扩展代价巨大，而注释和 XML 风格有它们独特的优势。最明显的就是 XML 风格可以控制切入点和通知的绑定。这对于扩展和配置方面非常有益，在下面一节中将讨论这点以及不同风格带来的其他优缺点。代码风格与注释和 XML 的比较那么，应当采用代码风格，还是用注释或 XML 声明方面呢？以下是基于 AspectJ 的 Java 代码的一
30、些技术的优缺点总结： 简明语法充分利用对 Java 代码的熟悉，减少键入错误，使错误更少。 切入点是一级实体，因此更容易对它们进行处理。 对于许多开发人员，用 XML 进行声明性编程要比用 Java 语言扩展更熟悉。 通知到切入点的绑定不能由开发人员控制。如果这个小结仍然无法缩小决策范围，那么不要担心。除了用每种风格编写这些方面的感觉之外，还有更多需要考虑的东西。当在下一节中查看语义的时候，语法决策还会出现，而且也会影响在第 2 部分中讨论的工具支持。语义的相似性虽然工具的方面声明风格之间存在主要的语法差异，但是核心的 AOP 语义是类似的。每个工具都有完全相同的连接点模型的概念，都把连接点作
31、为 Java 程序中的关键点，把切入点作为匹配连接点的机制，把通知作为指定连接点匹配时执行操作的机制。表 3和表 4总结了每种技术的语义。您可以注意到，命令规范上有许多微小的差异和变化，但是各种技术最终聚合在相同的核心概念上。这种聚合有很大的好处，因为这意味着学习曲线很容易从一项 AOP 技术转移到另外一项 AOP 技术。剩下来要考虑的就是每种技术的差异所带来的优劣了。回到连接点一个 AOP 工具连接点模型的表达方式决定了可用的连接点粒度，以及连接点如何匹配。每个 AOP 工具都提供了大量用于连接点匹配的原生切入点。有些原生切入点只与特定类型的连接点匹配（例如，方法执行）。其他切入点能够根据连接点的公共属性（例如，在某个控制流程中的所有连接点）匹配任何类型的连接点。连接点的类型以及它们特定的切入点，可以分成以下几组： 调用（Invocation） 调用或执行方法和其他代码元素时的点。 初始化（Initialization） 初始化类和对象时的点。 访问（Access） 读写某些字段时的点。 异常处理（Exception handling） 抛出和处理异常与错误时的点。另外，也支持以下没有类型的切入点分类： 控制流程（Control flow） 在某个流程控制流程中的连接点。 包含（Containment） 与包含在某个类或方法中的代码位
