[浅空滑行 编程模式系列]AOP Alliance (Java/J2EE AOP standards) －－ Why Did We Get In?

                           White Paper Draft
               The AOP Alliance: Why Did We Get In?

                    注:这是介绍AOP联盟项目的文档,这只是一个草稿,详情可以查看参考资源中给出的连接.

1. Introduction

The aim of this document is to present the AOP Alliance project. Its goals, its philosophy, what answers it should provide, and what it should not. It is a draft proposal which has to be further discussed with other members of the AOP Alliance in order to reach a common view on what we are doing here. It should also be
completed as soon as an interesting point comes out from the discussions on the list.

This document is a white paper and can be used on internal purpose by the AOP Alliance members, but also to provide an insight and an understanding about what is AOP Alliance for external people.

这个文档的目标是介绍AOP联盟项目。它的目标，它的哲学体系，针对解决哪方面问题，哪方面不提供支持。这只是一个建议的草稿。它必须与AOP联盟中成员进一步讨论，在我们正在做什么达成共识。一旦讨论列表中有新的关注点出现，它也将完成它。

这个AOP联盟成员内部使用的白皮书，但是也提供一种观点和理解

In section 1, I will try to explain in general terms the goals of the AOP Alliance. Our motivations comes
from the fact that AOP can improve solutions such as J2EE-based ones. If we manage to define a normalize set
 of APIs, it would be possible to integrate AOP in existing solutions or to build AOP environments using
existing AOP tools. Section 2 gives an overview of a proposed architecture and APIs for aspect-oriented
environments. I try to guess what APIs should be specified by the AOP Alliance. Finally, in section 3, I
enter into the details of the identified components and their roles within AOP environments.

第1节，我将尝试用基本的术语来介绍AOP联盟的目标。我们的动机来自于AOP能改进解决方法这样一个事实，比如基于J2EE的解决方案。如果我们定义一些规范化集合的APIs，AOP则可能集成到现存的解决方案中或者使用已有的AOP工具构建AOP环境。在第2节中对面向方面环境的提议架构和APIs做了一个概述。我尝试推测AOP联盟应该加入哪些APIs。最后第3节中，详细介绍标识组件和其在AOP环境中所扮演的角色。

2. AOP Alliance goals

2.1 AOP Advantages: The J2EE Case

Aspect-Oriented Programming (AOP) is a great way for designing and programing the applications. It offers a
 better solution to many problems than do existing technologies such as EJB.

面向方面变成一种设计和编写程序伟大的方式。针对一些问题它提供了比现有的一些技术更好的解决方案，比如EJB。

J2EE is a typical target environment (but not the only one) that could benefit from AOP Alliance. Indeed,
 J2EE environments partially solve some issues by providing means to handle technical issues such as
persistence or transactions. However, the J2EE architecture is not flexible enough to easilly add new
technical concerns related to particular needs. Moreover, it would be interesting to be able to remove one
solution when not needed or when a ligther solution is preferable

J2EE是一个能从AOP联盟中获取好处的典型的目标环境（但不是唯一）。确实，J2EE环境部分的解决了一些关注问题,比如事务或持久化.但是J2EE 架构在为特定的需要增加新的关注点方面不够灵活.并且,当一个解决方案不需要或者有一个更轻量的解决方案时,能删除现有方案也很值得关注.

AOP provides a generic means to build new technical concerns (crosscutting concerns) and to plug them within
 an application in a flexible and modular way. Applying some AOP concepts in J2EE can also really simplify
its use. For instance, regular Java objects (POJOs) can be used in place of EJBs. So, being able to easily
apply full AOP to J2EE will greatly increase the usability of J2EE. It would also bring much more power to
J2EE-compliant application servers.

AOP提供了一个通用操作方式构建新的技术关注点.(横切关注点)并且灵活的以模块化的方式嵌入应用程序中去.在J2EE中应用一些AOP关注点确实能简 化它的使用,比如.普通的Java对象(POJOs)能替换EJBs,所以,可以很容易的在J2EE中应用full AOP,会极大的提高J2EE的可用性.它也可以给J2EE应用服务器带来更强大的力量.

2.2 The Current Brakes To AOP

AOP is gaining in popularity. However, most of the AOP tools were not designed in the purpose to be applied in any environment (mainly because most of the tools where designed on experimentation purpose). Thus, when trying to use AOP in a specific environment, we can face some issues because, for instance, the environment already supports some builtin aspects that may not be compliant with the AOP tool implementation.

虽然众所周知AOP是有益的，但是大部分AOP工具设计应用于所有环境（主要是因为大部分工具只是用来实验）。所以当我们尝试在一个特定的环境下使用AOP，例如，很多实际场合，指定环境已经存在一些不适应AOP实现工具的方面

This problem arises because AOP needs to modify the objects/classes of the application in order to work fine.
 This objet-modification logic is implemented by a specific part of the AOP tool: the weaver. A weaver can be
 well-fitted to a given environment but could break some important system properties in another one. For
instance, an interesting discussion on the AOP Alliance's list beetween Gregor and Rickard seemed to show
that AspectJ's weaver implementation for introductions (specific weaving operations) was not well fitted in some environments having some kinds of distribution and persistence cacabilities.

这个问题的发生是因为AOP必须修改应用程序的对象/类来使其工作。对象的修改逻辑有AOP工具的指定的部分实现：weaver。一个weaver可能适合某一个指定环境，但是可能在另外一个环境中违反一些重要的系统属性。例如：在AOP联盟的list中，在Gregor 和Rickard之间一个关于AspectJ’s weaver实现不适合一些有用一些分布式和持续化能力的环境的介绍（weaving操作细节）

2.3  The AOP Alliance Claim

Most of the people here do not believe in the perfect system. We think that a system is always suited to a
given problem and environment (it does not necesseraly fit the other one). This is exactly the case for the AOP tools that we may use within complex environments such as J2EE. Depending on the faced problem, it would be useful to have a specific implementation of AOP.

大部分人不相信完美的系统。我们认为系统总是只适合特定的问题和环境（它不必要适合其它系统）。这正是AOP工具在复杂的环境，比如J2EE中使用的场合。面对这个难题，使用AOP的一个指定实现可能很有用处。

There are already a lot of specific implementations of AOP or AOP-related techniques such as generic proxies,
 interceptors, or bytecode translators. For instance, among others:

    * AspectJ: an AO source-level (and bytecode-level) weaver. New Language.
    * AspectWerkz: an AO framework (bytecode-level dynamic weaver+configuration in XML).
    * BCEL: a bytecode translator.
    * JAC: an AO middleware (bytecode-level dynamic weaver+configuration+aspects). Framework.
    * Javassist: a bytecode translator with a high-level API.
    * JBoss-AOP: interception and metadata-based AO framework (running on JBoss application sever + a standal
      one version).
    * JMangler: a bytecode translator with a composition framework for translations.
    * Nanning: an AO weaver (framework).
    * Prose: an AO bytecode-level dynamic weaver (framework).

已经有很多特定的AOP实现或者AOP相关的技术，比如generic proxies, interceptors, or bytecode translators，例如下面这些：

* AspectJ: 一个面向方面源码层（和字节码层）weaver，新语言.
    * AspectWerkz: 一个面向方面的框架 (字节码层动态weaver+XML配置).
    * BCEL: 一个字节码转换器.
    * JAC: 一个面向方面的中间件 (字节码层动态weaver+配置+方面 ). 框架.
    * Javassist: 使用high-level API的一个字节码转换器.
    * JBoss-AOP: 拦截和基于metadata的框架 (运行在JBoss服务器上+ 一个独立的版本).
    * JMangler: 使用一个转换的混合框架的一个字节码转换器。
    * Nanning: 一个面向方面的weaver（框架）
    * Prose: 一个面向方面的字节码层的动态weaver（框架）

To us, these implementations reflect that there is no good or bad implementations, but implementations
suited to some problems/environments.

So, the AOP Alliance goal is neither to come with a new AOP model, nor to provide a great AOP implementation
 that will work for all the cases or on a given J2EE application server. The AOP Alliance goal is rather to enable all the exisiting implementations to speak the same core language in order to:

    * avoid re-building of existing AOP components by reusing them,
    * simplify the adaptation of existing AOP components for a given target environment (typically a J2EE environment),
    * simplify the aspects reusing by having a common root AOP API.
    * simplify the implementation of development tools that whish to integrate AOP features.

上面这些实现表明：这些实现没有好坏之分，只是针对于某些问题和环境。

所以，AOP联盟的目标既不是创建一个新的AOP模型，也不是提供一个具体的AOP实现满足所有的情形或者满足在一个J2EE应用服务器上运行。AOP联盟的目标是确保所有已经存在的实现使用相同的核心语言。

• 避免重建已经存在的AOP组件
• 在特定环境下简化适应已经存在的AOP组件（特别是J2EE环境）。
• 简化准备集成AOP特性的开发工具的实现。

3.Aspect-Oriented Architectures


3.1 A Common Architectural Vision

In sections 1.2 and 1.3, we explain that it is difficult to agree on a common AOP model and implementation
because it is too tightly linked to the context of use and the environment (implementation may differ in a
pure Java approach and in a J2EE-compliant approach). However, we think that it is possible to agree on a
common architectural vision for Aspect Oriented Environnments (AOE).

在1.2和1.3节中，我么解释了与一个通用的AOP模型和实现保持一致时比较困难的，因为它与环境和使用上下午紧密关联（实现可能不是纯Java途径）。但是我们想为面向方面环境（AOE）使用一致的通用架构愿景。

Indeed, when building an Aspect-Oriented Environment (AOE)1, designers need to define an architecture. In
most of the existing AOEs, the architecture defines and combines some elementary modules/components/APIs that
 implement the basic functions of the system. By looking at the existing tools, we can identify common
components (i.e. components that provides close functionalities in the considered architecture, but not
necesseraly using the same implementation techniques). For instance, JBoss' weaver uses Javassist to
implement an interception mechanism (which is instrumented at the client's side) whilst JAC's weaver uses BCEL
 to implement an interception mechanism (which is instrumented at the server's side). Other techniques like intercessing the JIT compiler can be employed to perform the same effect. All of them heavily rely on the
environment.


In the next section, we will try to extract components that can be useful to AOEs. These components may be used to build contextual-dependent AOEs.

确实，构建一个AOE，设计者必须定义一个架构。在大部分存在AOEs中，这些架构定义和聚合了modules/components/APIs这 些元素实现了系统的基本功能。通过观察已经存在的工具，我们能识别出通用的组件（也就是在架构考虑中那些提供密切功能，但是可使用不同技术的的组件）.比 如JBoss的weaver使用Javassist实现一个拦截机制（在客户端使用）。同时JAC的weaver使用BCEL实现。一个拦截机制（在服务 器端使用）。其它机制比如植入JIT编译器也能达到相同的想过。所有这些都严重依赖于环境。

下一节，我们尝试抽出AOEs中使用的组件。这些组件可能被用于构建上下文依赖（contextual-dependent）的
AOEs。

Footnotes
 (AOE)1
With AOE, we mean any environment that supports AOP in one way or another. E.g. JBoss AOP is an AOE but any J2EE application server can be also regarded as a reduced AOE with buit-in aspects.

Footnotes：

意思是任何环境提供一种方法支持。比如。JBoss是一个AOE。而任何J2EE应用服务器也能看作一个内建方面简化的AOE。

3.2 A 3-Layer Typical Architecture

图 1

A typical architecture could be drawn as shown in figure 1. This simplified diagram contains some components
 (boxes) and some core logics (rounded boxes) that can use (bold arrows) the components' APIs. It is meant to
 run an initial AO program on the top of the figure. Note that this architecture does not intend to be a
reference architecture but only one possible architecture. Indeed, several possibilities exist for composing
 the different core components of an AO architecture.

One can split this architecture in three layers:

    * a low-level layer (1) that provides basic components to implement the weaving (the main process of AOP)
      on the target platform,
    * a high-level layer (2) that provides basic components for AOP, in its original meaning, plus the logic
       that implements the AO semantics (would depend on the target platform),      
    * a development-level layer (3) that includes the UI in its largest sense (can be supported by a language
 , can be a modelling tool) and other tools that are needed to help the developer trusting the AO programs  (such as type-checking, visualization tools, debuggers, and so on).

一个典型的架构像图1中描述的那样。这个简单图包含一些组件（方框），和一些核心的逻辑（圆框），这些逻辑可以使用（粗箭头）组件的APIs。注意这个架构不打算作为一个参考书目的架构，只是一个可能的架构。确实。使用不同的核心组件组建一个AO架构存在多种可能性。

这个架构可以分为三层：

l          一个low-level层(1)提供基本的组件实现指定平台的weaving（AOP主要过程）

l          一个 high-level层(2)提供AOP的基本组件，在原始意图中在上实现AO语义的逻辑。（依赖制定的目标平台）

l          一个development-level层(3)，包括相关的UI（能支持一种语言，是一种建模工具），并且需要其他功能帮助开发者信任这个AO程序（比如类型检查，可视化工具，调式器等）

3.3 What Shall AOP Alliance Specify Here?

As said before, the AOP Alliance goals are not to provide new models or better implementations of existing
tools. In fact, the AOP Alliance goals are to specify normalized API for the components that are identified in common Aspect Oriented Environments (AOEs) implementations. If we manage to do this, it will be possible to build better AOEs than existing ones by integrating the components that best fit the context in which we want to use AOP. In particular, it should be possible to use the very best of AOP, even in complex
environments such as J2EE application servers.

如以前所说，AOP联盟的目标不是提供一种新的模型或者对已有工具的一个更好实现。事实上。AOP联盟的目标就是为在通用的面向方面的环境实现（AOE）中标识的组件提供标准的API，如果我们设法这样做，可能会建立一个比已有的更好地AOEs，通过集成符合想使用AOP的context的组件。特别的，甚至在复杂环境中比如J2EE应用服务器中，AOP也可能用得很好。

So, if we refer to figure 1, the AOP Alliance's role should be to define the API of the identified components. The most important components are the low-level ones because their implementations will influence the
environment in which the AOE can be used. Some technical caracteristics may also have deep inpact on the
resulting system properties (e.g. are the aspects can be dynamically woven/unwoven? is the system scalable
regarding distribution? can the system cohabit with built-in aspects such as persistence or transactions?). However, the high-level components are also quite interesting for tools such as IDE, debuggers, modelling
tools, and so on. Having a common AOP concepts manipulation API will help the tools to better support several
 AOP implementations in different environments.

看图1，AOP联盟应该定义这标识组件的API，最重要的组件是low-level级的。因为这个实现将会影响使用AOE的环境。一些技术点可能深深的影响这个系统属性（比如，是否可以动态woven/unwoven？系统是否可分布式？是否可以和系统的内建方面共处，比如事务或持久化）。尽管如此。High-level的组件也是非常值得关注的，比如IDE，debuggers，建模工具等。拥有一个通用的AOP概念处理API将帮助工具更好的支持不同环境下的各种AOP实现。

The AOP Alliance could provide some reference implementations for some components (by using existing tools).
 However, it would be better if existing tools (most of the tools creators are in the Alliance) provide their
 own implementations of the defined APIs. These implementations will validate the API correctness.

AOP联盟可以提供一些组件的参考实现（使用已有的工具），当然如果存在的工具按照定义的APIs提供实现会更好（大部分工具基于联盟创建），这些实现会验证这些API的正确性。

The AOP Alliance will not tackle the weaving logic and the configuration logic since it really depends on the
 AOE implementation. However, we should also provide some reference implementation in order to show how our API should be used to build AOEs.

Finally, the AOP Alliance will not address the third layer (development-level). We should let the development
 tools implementors use our API when the AOP tools they integrate implement it.

一旦它真的以来AOE实现。AOP联盟不处理weaving逻辑和configuration逻辑。当然，我们会提供一些参考实现，关于如何使用我们的API构建AOEs。

最后，AOP联盟就不对development-level层处理了，当AOP工具进行集成时，我们让开发工具实现器使用我们的API实现它。

4. AOP Alliance Components

4.1 Low-Level Components

Low-level components are quite important ones because the entire AOE relies on them for its implementation.
 The way these components are implemented will be crutial and may drastically affect the system's properties
 such as performance, scalability, integration capabilities, or security.

Low-level组件是最重要的，因为整个的AOE依赖于它的实现，组件实现的方式是至关紧要的，可能彻底的影响系统属性，比如性能，可扩展性，集成能力，安全等。

4.1.1 Reflection

The reflection API is very important for any AOE. In fact, the weaver needs to introspects the classes of the
 base program in order to apply the advices or the introductions. For instance, if a pointcut tells that all the methods of a class should be adviced (using some kind of regular expression or an ALL keyword), then the
 weaver will need to use the reflection API to explicitely know the list of the methods that actually need to
 be adviced.
When the weaving process is done at runtime, the SUN's java.lang.reflect implementation can be sufficient to build the AOE. However, in most of the existing systems, the weaving process occurs at the compile-time or
at class load-time. In these cases, a specific implementation of a reflection API is needed. According to AOP
 Alliance, it is quite important to normalize this API in order to be able to switch the underlying
implementation depending on the running context of the AOE.

反射API对于AOE来说是非常重要的，事实上，weaver需要内省（introspects）基本程序的class，为了使用这个通知或介绍（introductions）。比如，如果一个pointcut告诉一个类所有的方法将被通知（使用一些正确表达式或所有关键字）。这个weaver将必须使用反射API清楚的知道哪些方法真正需要被通知。

当织入（weaving）过程已经在运行期处理。SUN的java.lang.reflect实现足够构建这个AOE，然而，在大部分已有的系统中。织入过程发生在编译时期或者在class加载时期。在这些情况下，需要一个反射API的制定实现，依据AOP联盟，规范化API是非常重要的，为了使依赖于AOE的运行上下文切换具体实现。

4.1.2 Program Instrumentation

From the weaver's point of view, if the reflection is the read access to the woven program, the instrumentation
 is the write access 2. However, in AOP, the allowed program modifications are a reduced set of modifications.
 The allowed modications are incremental regarding the existing structure of the initial program so that the
 aspects can be correctly composed together. These kinds of incremental modifications are called
instrumentations because of previous discussions on the list.

从织入点(weaver's point)的视角来看.,反射是读被织入的程序,设备(instrumentation)则是写操作(见footnote 2).但是,程序允许的修改(modifications)只是修改(modifications)中的一个子集,允许的修改的增强只是对对于程序化程序 已经存在的结构,以确保方面(aspects)能正确的组装起来.由于列表中原先的讨论,这种增强的修改被称作设备 (instrumentations).

There is no standard API for instrumentation. However, like reflection, instrumentation can happen at run
time, compile time, or load time. Moreover, for each category, different implementations can be performed
depending on the context and the AOE's environment (for instance, the instrumentation can be done directly
on the source code or on the bytecode). It is thus important to us that the instrumentation API is normalized in order to change the underlying implementation depending on the AOE requirements.

Footnotes
... access2
In reflection's foundations, this operation is called intercessio

设备(instrumentation)没有标准的API,但是象反射(reflection),设备(instrumentation)可以在运 行期,编译期或者是在加载期发生.并且,对于每一种,依赖上下文和AOE的环境能执行不同的实现(比如,instrumentation可以直接在源代码 或字节码上操作).为了能够依赖AOE需要,能切换不同的实现.规范化instrumentation API是非常重要的.

Footnotes
依据反射原则,这个操作称为intercession

4.1.3 Interception Frameworks

Another type of base components that can be extremely useful to build AOEs are the interception frameworks.
 With the dynamic proxies, Java provides a standard API/framework for interception. However, several
enhancements on transparency, performance, etc, can be achived by other implementations (most of them use an
 instrumentation API). It is thus also interesting to define a standard interception API/framework with a
clear semantics.

拦截框架(interception frameworks)是另一个对构建AOEs非常有帮助的基本组件.针对动态代理,Java为拦截提供了一个标准的API/framework.但是透 明度和性能等方面的一些提供可以通过其它的一些实现来完成(它们大部分使用一个instrumentation API),因此,使用一个清晰的语法定义个一个标准的拦截API/framework是值得关注的.

Interception frameworks have many advantages since they allow to implement very easily the around advices of
 the AOP model. Moreover, they can be standalone and most of the time provide quite clear AOP-like code
despite written in pure Java. For these reasons, several interception frameworks have been implemented in
many projects and environments (including J2EE application servers, see JBoss). Hence, the AOP Alliance
should provide an abstract interception framework in order to standardize this AOP important toolbox.

拦截框架有许多优势,因为它们可以很容易的实现AOP模型的around advices.他们可以单独存在的,并且大部分情况下提供的非常清晰AOP-like的代码(不管是不是Java写的).基于这些原因,很多拦截框架已 经在许多项目和环境种实现了.(包括J2EE应用服务器,see JBoss). 因此AOP联盟将提供一个抽象的拦击起框架标准化这个重要的AOP工具箱(toolbox).

4.1.4 Metadata Handling

Metadata handling is useful when implementing AOEs, especially when coupled with an interception framework. It allows the weaver to extend the classes semantics in a non-invasive manner. Since most implementations on
 metadata allows dynamicity, it can also be used for dynamic configuration/reconfiguration of the aspect

实现AOEs时,Metadata处理是很有用的,特别对于结合一拦截框架.它允许weaver用一种无侵入的方式(non-invasive manner)继承classes语义.由于大部分metadata上的实现允许动态的.所以它也可用于方面的(aspect)动态配置/重新装配 (onfiguration/reconfiguration)

Even if the JDK1.5 will provide a standard implementation for metadata, it should be useful to provide a
standard API that allows multiple implementations. These may take into account some environmental specificity
 such as distribution, serialization, that may not be correctly handled by the default implementation.

虽然JDK1.5提供了metadata的一个标准实现.但提供一个标准的API,允许多种实现还是很有用处的.这些可能是考虑到一些具体的,比如分布式,序列化的环境.默认实现可能不能正确的执行.

4.1.5 Class Loading Frameworks

In many AOEs, byte-code level manipulation is required. It can be used to implement an interception framework,
 or to directly implement the weaver's intrumentation of the programs. In some cases, this byte-code level
manipulation can be done at class's load-time because the AOP instrumentations are quite simple. Thus, most of the AOEs use the flexible class-loading architecture of Java.

在许多AOEs中.字节码层(byte-code level)的操作是必须的.它可用来实现一个拦截框架.或者直接实现程序的织入装备(weaver's instrumentation),有些情形.可以在类加载期进行字节码层操作,因为AOP instrumentations非常简单.所以大部分的AOEs使用Java的灵活的类加载架构.

However, several environments also use the class-loaders to implement their own functionalities. For instance,distributed environnments may generate the stubs using specific class loaders. Within these environments,the AOE's class-loading mechanism could lead to system crashes because of class-loaders incompatibilities.

Consequently, we think that it could be important to normalize a class-loading framework that would be flexible enough to easily enable different class loaders comming from different environment to cooperate in a safe way.

不过,有些环境也使用类加载器实现自身的功能,比如,分布式环境可能使用特定的类加载器生成存根(stubs).在这些环境中.由于类加载器不一致,这个AOE的类加载机制可能导致系统宕掉.

因为,我们认为标准化一个类加载框架是很重要的.这个框架要足够灵活,能确保来自不同环境中的类加载器能安全的协作.

4.2 High-Level Components

The high-level components are important to normalize if we want the tools defined in the third layer
(development layer) to provide better support for AOP in general.

如果想要第三层(development层)定义的工具对AOP提供更好的支持,标准化High-level组件是非常重要的.

4.2.1 AOP API

Explaining the goal of our AOP API can be explained great by quoting Gregor: ''Clearly we want to do whatever
 we can to avoid needless inconsistency among AOP tools. It is much too soon to actually standardize, we
still need room for meaningful variance. But needless variance is clearly worth eliminating.''

So, our AOP model will no be a new model. It will just try to bring together what all the current models have in common. The AspectJ model is doubtless the most achieved one and there are already some tools that support it. So we will probably take a subset of AspectJ here.

可以引用Gregor的一句话可以解释AOP API的目标:”我们要做的就是清除在AOP工具中任何可以避免的不必要的不协调,以便最快的达到实际的标准,我们仍然保留有意义的vriance.但无意义的vriance则需要明确的清除”

所以,我们的AOP模型不会是一个新的模型.而是组合现有模型的通用部分.AspectJ模型无疑是完成度最高的模型,并且已经有一些工具对其提供支持.因此我们将去AspectJ的一个子集.



4.2.2 Configuration API

Many aspects can be implemented in a generic fashion. This means that they implement a logic that is
potentially reusable for any program in which you would want to weave the aspect functions. Most of the time,
 this aspect-reusing process implies a parameterization of the generic aspect (for instance, tell a generic persistence aspect which class should be persistent and how). In AspectJ, this can be done by subclassing
abstract aspects. But it can also be done by using external tools (e.g. pre-processors). In J2EE environment,
 the configuration process of the built-in aspects (technical concerns of the EJB container) is parameterized
 by XML deployment files. In JBoss/AOP and other frameworks, the configuration can also be done using XML
files. In JAC, the configuration can be done in Java programs with the aspect configuration API or by using a specific scripting-like language, and so on.

很多aspects使用通用的风格来实现的.它们实现一个逻辑的方式有可能会被想织入方面功能(aspect functions)的任何程序重用.大多数情况下,方面重用(aspect-reusing)意味着一个通用方面(generic aspect)的参数(例如:告诉一个通用的持久化方面哪一个class应该持久化以及如何持久化). 在AspectJ中,.抽象方面(abstract aspects)的子类可以做到这点.而且它也可以使用外部的工具(例如:pre-processors). 在J2EE环境中,内建方面(EJB容器的技术关注点)的过程是通过XML部署文件来配置的.在JBOss/Aop和其它framworks中,也可以使 用XML,在JAC中可以使用aspect  configuration  API编写Java程序或者使用特别的scripting-like语言.等等.

It would be great if we could normalize a configuration API. It would make AOEs integration easier for
development tools. It would also facilitate the reusing of specific configurations from an AOE to another
(e.g. AspectJ and JBoss/AOP).
Note that it is maybe unrealistic to make the aspects portable from an AOE to another because of the
potentially important differences. But it seems less unrealistic to make the aspect configurations portable,
 which is already a first step towards AOEs interoperablity.

如果能标准化configuration API,那就非常棒.它将使开发工具更容易的集成AOEs.并且在不同的AOE中重用特定的配置更容易(比如AspectJ和JBoss/AOP)

注意,由于不同的AOE存在很大的区别,使方面(aspects)轻易的在不同的AOE中共同使用可能是不切实际的.但是让aspect configuration轻便一些,符合实际一些,这是AOEs之间能移植走出的第一步.





参考资源:
AOP Alliance http://aopalliance.sourceforge.net/