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


                    注:這是介紹AOP聯(lián)盟項目的文檔,這只是一個草稿,詳情可以查看參考資源中給出的連接.


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.


這個文檔的目標(biāo)是介紹AOP聯(lián)盟項目。它的目標(biāo)，它的哲學(xué)體系，針對解決哪方面問題，哪方面不提供支持。這只是一個建議的草稿。它必須與AOP聯(lián)盟中成員進一步討論，在我們正在做什么達成共識。一旦討論列表中有新的關(guān)注點出現(xiàn)，它也將完成它。

這個AOP聯(lián)盟成員內(nèi)部使用的白皮書，但是也提供一種觀點和理解


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節(jié)，我將嘗試用基本的術(shù)語來介紹AOP聯(lián)盟的目標(biāo)。我們的動機來自于AOP能改進解決方法這樣一個事實，比如基于J2EE的解決方案。如果我們定義一些規(guī)范化集合的APIs，AOP則可能集成到現(xiàn)存的解決方案中或者使用已有的AOP工具構(gòu)建AOP環(huán)境。在第2節(jié)中對面向方面環(huán)境的提議架構(gòu)和APIs做了一個概述。我嘗試推測AOP聯(lián)盟應(yīng)該加入哪些APIs。最后第3節(jié)中，詳細介紹標(biāo)識組件和其在AOP環(huán)境中所扮演的角色。




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.


面向方面變成一種設(shè)計和編寫程序偉大的方式。針對一些問題它提供了比現(xiàn)有的一些技術(shù)更好的解決方案，比如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聯(lián)盟中獲取好處的典型的目標(biāo)環(huán)境（但不是唯一）。確實，J2EE環(huán)境部分的解決了一些關(guān)注問題,比如事務(wù)或持久化.但是J2EE 架構(gòu)在為特定的需要增加新的關(guān)注點方面不夠靈活.并且,當(dāng)一個解決方案不需要或者有一個更輕量的解決方案時,能刪除現(xiàn)有方案也很值得關(guān)注.



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提供了一個通用操作方式構(gòu)建新的技術(shù)關(guān)注點.(橫切關(guān)注點)并且靈活的以模塊化的方式嵌入應(yīng)用程序中去.在J2EE中應(yīng)用一些AOP關(guān)注點確實能簡 化它的使用,比如.普通的Java對象(POJOs)能替換EJBs,所以,可以很容易的在J2EE中應(yīng)用full AOP,會極大的提高J2EE的可用性.它也可以給J2EE應(yīng)用服務(wù)器帶來更強大的力量.


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工具設(shè)計應(yīng)用于所有環(huán)境（主要是因為大部分工具只是用來實驗）。所以當(dāng)我們嘗試在一個特定的環(huán)境下使用AOP，例如，很多實際場合，指定環(huán)境已經(jīng)存在一些不適應(yīng)AOP實現(xiàn)工具的方面


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.


這個問題的發(fā)生是因為AOP必須修改應(yīng)用程序的對象/類來使其工作。對象的修改邏輯有AOP工具的指定的部分實現(xiàn)：weaver。一個weaver可能適合某一個指定環(huán)境，但是可能在另外一個環(huán)境中違反一些重要的系統(tǒng)屬性。例如：在AOP聯(lián)盟的list中，在Gregor 和Rickard之間一個關(guān)于AspectJ’s weaver實現(xiàn)不適合一些有用一些分布式和持續(xù)化能力的環(huán)境的介紹（weaving操作細節(jié)）


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.


大部分人不相信完美的系統(tǒng)。我們認(rèn)為系統(tǒng)總是只適合特定的問題和環(huán)境（它不必要適合其它系統(tǒng)）。這正是AOP工具在復(fù)雜的環(huán)境，比如J2EE中使用的場合。面對這個難題，使用AOP的一個指定實現(xiàn)可能很有用處。


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).


已經(jīng)有很多特定的AOP實現(xiàn)或者AOP相關(guān)的技術(shù)，比如generic proxies, interceptors, or bytecode translators，例如下面這些：

* AspectJ: 一個面向方面源碼層（和字節(jié)碼層）weaver，新語言.
    * AspectWerkz: 一個面向方面的框架 (字節(jié)碼層動態(tài)weaver+XML配置).
    * BCEL: 一個字節(jié)碼轉(zhuǎn)換器.
    * JAC: 一個面向方面的中間件 (字節(jié)碼層動態(tài)weaver+配置+方面 ). 框架.
    * Javassist: 使用high-level API的一個字節(jié)碼轉(zhuǎn)換器.
    * JBoss-AOP: 攔截和基于metadata的框架 (運行在JBoss服務(wù)器上+ 一個獨立的版本).
    * JMangler: 使用一個轉(zhuǎn)換的混合框架的一個字節(jié)碼轉(zhuǎn)換器。
    * Nanning: 一個面向方面的weaver（框架）
    * Prose: 一個面向方面的字節(jié)碼層的動態(tài)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.


上面這些實現(xiàn)表明：這些實現(xiàn)沒有好壞之分，只是針對于某些問題和環(huán)境。

所以，AOP聯(lián)盟的目標(biāo)既不是創(chuàng)建一個新的AOP模型，也不是提供一個具體的AOP實現(xiàn)滿足所有的情形或者滿足在一個J2EE應(yīng)用服務(wù)器上運行。AOP聯(lián)盟的目標(biāo)是確保所有已經(jīng)存在的實現(xiàn)使用相同的核心語言。

  • 避免重建已經(jīng)存在的AOP組件
  • 在特定環(huán)境下簡化適應(yīng)已經(jīng)存在的AOP組件（特別是J2EE環(huán)境）。
  • 簡化準(zhǔn)備集成AOP特性的開發(fā)工具的實現(xiàn)。



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節(jié)中，我么解釋了與一個通用的AOP模型和實現(xiàn)保持一致時比較困難的，因為它與環(huán)境和使用上下午緊密關(guān)聯(lián)（實現(xiàn)可能不是純Java途徑）。但是我們想為面向方面環(huán)境（AOE）使用一致的通用架構(gòu)愿景。


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.


確實，構(gòu)建一個AOE，設(shè)計者必須定義一個架構(gòu)。在大部分存在AOEs中，這些架構(gòu)定義和聚合了modules/components/APIs這 些元素實現(xiàn)了系統(tǒng)的基本功能。通過觀察已經(jīng)存在的工具，我們能識別出通用的組件（也就是在架構(gòu)考慮中那些提供密切功能，但是可使用不同技術(shù)的的組件）.比 如JBoss的weaver使用Javassist實現(xiàn)一個攔截機制（在客戶端使用）。同時JAC的weaver使用BCEL實現(xiàn)。一個攔截機制（在服務(wù) 器端使用）。其它機制比如植入JIT編譯器也能達到相同的想過。所有這些都嚴(yán)重依賴于環(huán)境。

下一節(jié)，我們嘗試抽出AOEs中使用的組件。這些組件可能被用于構(gòu)建上下文依賴（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：

意思是任何環(huán)境提供一種方法支持。比如。JBoss是一個AOE。而任何J2EE應(yīng)用服務(wù)器也能看作一個內(nèi)建方面簡化的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).


一個典型的架構(gòu)像圖1中描述的那樣。這個簡單圖包含一些組件（方框），和一些核心的邏輯（圓框），這些邏輯可以使用（粗箭頭）組件的APIs。注意這個架構(gòu)不打算作為一個參考書目的架構(gòu)，只是一個可能的架構(gòu)。確實。使用不同的核心組件組建一個AO架構(gòu)存在多種可能性。

這個架構(gòu)可以分為三層：

l          一個low-level層(1)提供基本的組件實現(xiàn)指定平臺的weaving（AOP主要過程）

l          一個 high-level層(2)提供AOP的基本組件，在原始意圖中在上實現(xiàn)AO語義的邏輯。（依賴制定的目標(biāo)平臺）

l          一個development-level層(3)，包括相關(guān)的UI（能支持一種語言，是一種建模工具），并且需要其他功能幫助開發(fā)者信任這個AO程序（比如類型檢查，可視化工具，調(diào)式器等）



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聯(lián)盟的目標(biāo)不是提供一種新的模型或者對已有工具的一個更好實現(xiàn)。事實上。AOP聯(lián)盟的目標(biāo)就是為在通用的面向方面的環(huán)境實現(xiàn)（AOE）中標(biāo)識的組件提供標(biāo)準(zhǔn)的API，如果我們設(shè)法這樣做，可能會建立一個比已有的更好地AOEs，通過集成符合想使用AOP的context的組件。特別的，甚至在復(fù)雜環(huán)境中比如J2EE應(yīng)用服務(wù)器中，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聯(lián)盟應(yīng)該定義這標(biāo)識組件的API，最重要的組件是low-level級的。因為這個實現(xiàn)將會影響使用AOE的環(huán)境。一些技術(shù)點可能深深的影響這個系統(tǒng)屬性（比如，是否可以動態(tài)woven/unwoven？系統(tǒng)是否可分布式？是否可以和系統(tǒng)的內(nèi)建方面共處，比如事務(wù)或持久化）。盡管如此。High-level的組件也是非常值得關(guān)注的，比如IDE，debuggers，建模工具等。擁有一個通用的AOP概念處理API將幫助工具更好的支持不同環(huán)境下的各種AOP實現(xiàn)。


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聯(lián)盟可以提供一些組件的參考實現(xiàn)（使用已有的工具），當(dāng)然如果存在的工具按照定義的APIs提供實現(xiàn)會更好（大部分工具基于聯(lián)盟創(chuàng)建），這些實現(xiàn)會驗證這些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實現(xiàn)。AOP聯(lián)盟不處理weaving邏輯和configuration邏輯。當(dāng)然，我們會提供一些參考實現(xiàn)，關(guān)于如何使用我們的API構(gòu)建AOEs。

最后，AOP聯(lián)盟就不對development-level層處理了，當(dāng)AOP工具進行集成時，我們讓開發(fā)工具實現(xiàn)器使用我們的API實現(xiàn)它。


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依賴于它的實現(xiàn)，組件實現(xiàn)的方式是至關(guān)緊要的，可能徹底的影響系統(tǒng)屬性，比如性能，可擴展性，集成能力，安全等。


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需要內(nèi)省（introspects）基本程序的class，為了使用這個通知或介紹（introductions）。比如，如果一個pointcut告訴一個類所有的方法將被通知（使用一些正確表達式或所有關(guān)鍵字）。這個weaver將必須使用反射API清楚的知道哪些方法真正需要被通知。

當(dāng)織入（weaving）過程已經(jīng)在運行期處理。SUN的java.lang.reflect實現(xiàn)足夠構(gòu)建這個AOE，然而，在大部分已有的系統(tǒng)中。織入過程發(fā)生在編譯時期或者在class加載時期。在這些情況下，需要一個反射API的制定實現(xiàn)，依據(jù)AOP聯(lián)盟，規(guī)范化API是非常重要的，為了使依賴于AOE的運行上下文切換具體實現(xiàn)。


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)的視角來看.,反射是讀被織入的程序,設(shè)備(instrumentation)則是寫操作(見footnote 2).但是,程序允許的修改(modifications)只是修改(modifications)中的一個子集,允許的修改的增強只是對對于程序化程序 已經(jīng)存在的結(jié)構(gòu),以確保方面(aspects)能正確的組裝起來.由于列表中原先的討論,這種增強的修改被稱作設(shè)備 (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

設(shè)備(instrumentation)沒有標(biāo)準(zhǔn)的API,但是象反射(reflection),設(shè)備(instrumentation)可以在運 行期,編譯期或者是在加載期發(fā)生.并且,對于每一種,依賴上下文和AOE的環(huán)境能執(zhí)行不同的實現(xiàn)(比如,instrumentation可以直接在源代碼 或字節(jié)碼上操作).為了能夠依賴AOE需要,能切換不同的實現(xiàn).規(guī)范化instrumentation API是非常重要的.

Footnotes
依據(jù)反射原則,這個操作稱為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)是另一個對構(gòu)建AOEs非常有幫助的基本組件.針對動態(tài)代理,Java為攔截提供了一個標(biāo)準(zhǔn)的API/framework.但是透 明度和性能等方面的一些提供可以通過其它的一些實現(xiàn)來完成(它們大部分使用一個instrumentation API),因此,使用一個清晰的語法定義個一個標(biāo)準(zhǔn)的攔截API/framework是值得關(guān)注的.

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.


攔截框架有許多優(yōu)勢,因為它們可以很容易的實現(xiàn)AOP模型的around advices.他們可以單獨存在的,并且大部分情況下提供的非常清晰AOP-like的代碼(不管是不是Java寫的).基于這些原因,很多攔截框架已 經(jīng)在許多項目和環(huán)境種實現(xiàn)了.(包括J2EE應(yīng)用服務(wù)器,see JBoss). 因此AOP聯(lián)盟將提供一個抽象的攔擊起框架標(biāo)準(zhǔn)化這個重要的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


實現(xiàn)AOEs時,Metadata處理是很有用的,特別對于結(jié)合一攔截框架.它允許weaver用一種無侵入的方式(non-invasive manner)繼承classes語義.由于大部分metadata上的實現(xiàn)允許動態(tài)的.所以它也可用于方面的(aspect)動態(tài)配置/重新裝配 (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的一個標(biāo)準(zhǔn)實現(xiàn).但提供一個標(biāo)準(zhǔn)的API,允許多種實現(xiàn)還是很有用處的.這些可能是考慮到一些具體的,比如分布式,序列化的環(huán)境.默認(rèn)實現(xiàn)可能不能正確的執(zhí)行.


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中.字節(jié)碼層(byte-code level)的操作是必須的.它可用來實現(xiàn)一個攔截框架.或者直接實現(xiàn)程序的織入裝備(weaver's instrumentation),有些情形.可以在類加載期進行字節(jié)碼層操作,因為AOP instrumentations非常簡單.所以大部分的AOEs使用Java的靈活的類加載架構(gòu).


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.


不過,有些環(huán)境也使用類加載器實現(xiàn)自身的功能,比如,分布式環(huán)境可能使用特定的類加載器生成存根(stubs).在這些環(huán)境中.由于類加載器不一致,這個AOE的類加載機制可能導(dǎo)致系統(tǒng)宕掉.

因為,我們認(rèn)為標(biāo)準(zhǔn)化一個類加載框架是很重要的.這個框架要足夠靈活,能確保來自不同環(huán)境中的類加載器能安全的協(xié)作.


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提供更好的支持,標(biāo)準(zhǔn)化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的目標(biāo):”我們要做的就是清除在AOP工具中任何可以避免的不必要的不協(xié)調(diào),以便最快的達到實際的標(biāo)準(zhǔn),我們?nèi)匀槐Ａ粲幸饬x的vriance.但無意義的vriance則需要明確的清除”

所以,我們的AOP模型不會是一個新的模型.而是組合現(xiàn)有模型的通用部分.AspectJ模型無疑是完成度最高的模型,并且已經(jīng)有一些工具對其提供支持.因此我們將去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使用通用的風(fēng)格來實現(xiàn)的.它們實現(xiàn)一個邏輯的方式有可能會被想織入方面功能(aspect functions)的任何程序重用.大多數(shù)情況下,方面重用(aspect-reusing)意味著一個通用方面(generic aspect)的參數(shù)(例如:告訴一個通用的持久化方面哪一個class應(yīng)該持久化以及如何持久化). 在AspectJ中,.抽象方面(abstract aspects)的子類可以做到這點.而且它也可以使用外部的工具(例如:pre-processors). 在J2EE環(huán)境中,內(nèi)建方面(EJB容器的技術(shù)關(guān)注點)的過程是通過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.

如果能標(biāo)準(zhǔn)化configuration API,那就非常棒.它將使開發(fā)工具更容易的集成AOEs.并且在不同的AOE中重用特定的配置更容易(比如AspectJ和JBoss/AOP)

注意,由于不同的AOE存在很大的區(qū)別,使方面(aspects)輕易的在不同的AOE中共同使用可能是不切實際的.但是讓aspect configuration輕便一些,符合實際一些,這是AOEs之間能移植走出的第一步.





參考資源:
AOP Alliance http://aopalliance.sourceforge.net/