《AOP 工具比较.doc》由会员分享，可在线阅读，更多相关《AOP 工具比较.doc（12页珍藏版）》请在金锄头文库上搜索。
1、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 部分没有形成一个独立的下载或用户社团，所以用户基数相当比例的用户可能没有给 Spring A
7、OP 发贴，而是投在别的主题上了。在 上还列出了 4 个额外的工具，但是它们要么缺乏用户讨论论坛，要么在 11 月没有贴子。AOP 工具虽然没有列在表中前四位，但它在技术上可能非常成熟，可是缺乏较大的用户基数就意味着它们还没有经受过采纳程度测试。虽然在本文编写的时候，它们还不适合于商业开发，但是这些工具的日后发展还是值得关注的。通过上表的比较，还可以看出非 Java 平台的 AOP 工具没有 Java 平台的工具成熟，但是应当注意 .NET 和 C+ 工具的用户社区正在成长。根据表 1，可以看出，从用户采用度的角度来说，AspectJ、AspectWerkz、JBoss AOP 和 Spri
8、ng 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 框架的扩展发布。版本更新到 1.1.3
9、.都是为了连接点本文介绍的每个 AOP 工具都采用了连接点（join point）模型和机制，显式地声明程序的横切结构。虽然各个工具实现这个框架的技术非常相似，但是理解底层机制对于了解每项技术的优劣是非常重要的。在这一节中，将回顾 AOP 的连接点模型以及利用连接点模型的语言模型。支持机制AOP 工具的设计目标是把横切的问题（例如认证和事务管理）模块化。在单独使用面向对象技术实现的的时候，处理这些问题的代码会分散在整个系统中，这种分散造成管理和发展横切结构时出现不必要的困难。与对象提供了一种能够清楚地捕获继承结构的语言机制类似，AOP 也为横切问题的良好模块化提供了同样的好处。位于每个 AOP
10、 工具核心的是连接点模型，它提供了一种机制，可以识别出在哪里发生了横切。连接点就是主程序和方面相遇的地方。静态连接点允许方面定义类上的新成员。动态连接点是方面执行与程序执行相遇的地方。例如，普通的 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 字段和方法之外包含这三类成员。方面代表一套模块化良好的横切结构。如下所示，不同的 AO
14、P 技术实现这些方法的技术各不相同。但是，每种技术的核心，都是连接点的访问、编辑、命名和抽象机制。切入点可以通过显式枚举方式描述连接点集合。应当用一个示例指定图 1所示的Account的利息的三个方法调用。虽然枚举可能很有用，但是用结构化属性的方式表示连接点通常更方便。这类基于属性的切入点可以表示一套与“每个针对Account子类型的调用”匹配的连接点，却不必强迫程序员枚举这些子类型。这样做可以保证向系统添加由Account扩展的新类时，新类会自动与切入点匹配。切入点支持复合（composition），这就允许把简单的 切入点组合成更复杂的切入点。例如，可以把所有Account调用的切入点限制
15、在那些针对特定类或控制流程进行的调用中。切入点的命名（naming）机制提高了可读性和复合性。对抽象（abstraction）与具体化（concretization）的支持，可以更加容易地创建通用库，对于要应用库的特定应用程序的切入点来说，这些库可以独立定义。最后，对切入点中公开连接点状态的支持允许对诸如正在执行对象和方法参数之类的访问事项进行商量。方面比较如前所述，所有 AOP 工具的底层机制都是连接点和切入点、通知和类型间声明的概念。在这些工具中，可以注意到的主要区别就是方面声明编写及应用到系统上的方式。这些工具可用以下方法中的一种进行方面声明：使用类似 Java 的代码、注释或 XML。
16、对于某些开发人员来说，熟悉用 Java 语言编程方面的知识，要比熟悉语言扩展技术的优劣更重要，这些内容会在后面的小节中讨论。对于其他人来说，了解注释和 XML 技术在集成上的优势，要比痛苦地把切入点当作字符串来操作更重要。在这一节中，将使用一个常见的示例指出每个工具在方面声明技术上的差异。请考虑图 1所示的Account类的授权策略这样一个示例。在面向对象的实现中，最常见到的，就是对认证的调用分散在Account类的众多方法以及需要认证的其他类中。在 AOP 实现中，可以明确地用一个方面捕获这个行为，而不必修改操纵帐户的代码。不管使用什么工具声明，这个方面都需要具备以下特征： 一个切入点，捕捉banking
