JAVA平臺AOP技術研究

3.1 Java平臺AOP技術概覽

3.1.1 AOP技術在Java平臺中的應用

AOP在實驗室應用和商業應用上，Java平臺始終走在前面。從最初也是目前最成熟的AOP工具——AspectJ，到目前已經融和在企業級容器JBoss中的JBoss AOP，均創建在Java平臺上。

前面已經描述到，AOP的目的就是將核心關注點和橫切關注點分離，實際上這就是一種分散關注（seperation of concerns）的思路。在Java平臺下，若是要開發企業級的應用，非J2EE莫屬。一個J2EE應用系統只有部署在J2EE容器中才能運行，那麼爲何要劃分爲J2EE容器和J2EE應用系統？ 經過對J2EE容器運行機制的分析，咱們發現：實際上J2EE容器分離了通常應用系統的一些通用功能，例如事務機制、安全機制以及對象池或線程池等性能優化機制。這些功能機制是每一個應用系統幾乎都須要的，所以能夠從具體應用系統中分離出來，造成一個通用的框架平臺，並且，這些功能機制的設計開發有必定難度，同時運行的穩定性和快速性都很是重要，必須通過長時間調試和運行經驗積累而成，所以，造成了專門的J2EE容器服務器產品，如Tomcat JBoss、Websphere、WebLogic等。

從J2EE將應用系統和容器分離的策略，咱們可以看到AOP的影子。J2EE應用系統就至關於AOP技術中的核心關注點，它的內容主要包括企業系統的商業邏輯；而J2EE容器則相似於橫切關注點，實現的是通用的功能機制。不過業界在選擇J2EE容器時，對於EJB這種重量級容器服務器而言，雖然欣賞其高效、穩定及企業級的容器服務，但對於整個容器的高開銷、高成本以及過於複雜的解決方案均深懷戒心。所以，隨着J2EE的逐步演化，「輕量級容器架構」經過開源社區如激流通常的驅動力，逐漸佔據了J2EE技術的強勢地位。而所謂「輕量級容器」與EJB提供的重量級架構的區別，就在於藉助了AOP技術和IoC（Inversion of Control，反轉模式）機制，下降了代碼對於專用接口的依賴性，以簡短、輕便、專一、可移植的方式實現業務對象。事實上，咱們看到的美好前景是，若是全部企業級服務均可以經過AOP機制提供給普通Java對象，那麼深盔重鎧的應用服務器就再也不有存在的價值了。

正是看到了AOP技術在企業級開發中的巨大潛力，而「輕量級容器」也喚起了改革EJB容器的呼聲（事實上，最新的 EJB V3.0 標準就使用了輕量級容器模型），愈來愈多的AOP工具在Java平臺下應運而生，從而造成了目前AOP工具百家爭鳴的局面。其中，應用最爲普遍的主要包括AspectJ、Spring AOP和JBoss AOP等。

3.1.2 Java平臺下AOP工具的比較

AOP是一項新技術，而在Java平臺下實現該技術的工具也很是多。雖然AOP的技術要素從本質上來說是一致的，但各類工具的實現方法也各有不一樣，本節基於AOP的技術要素，對當前應用較普遍的AspectJ、Spring AOP和JBoss AOP進行比較。

3.1.2.1 AOP實現機制的區別

一樣是實現AOP，且AOP的技術要素徹底相同，但各類AOP工具對於AOP實現的底層機制倒是不盡相同的。

AspectJ採用了源代碼生成技術來實現AOP。它提供了一套獨有的基於Java平臺的AOP語法，以及專有的AspectJ編譯器。編譯器在編譯具備AspectJ語法的Java程序時，可以識別諸如aspect，pointcut等特殊關鍵字，而後利用靜態織入的方式，修改須要被截取的方法所屬類的源代碼，把advice或者introduce的業務邏輯代碼注入到正確的位置。利用AspectJ，能夠將核心關注點徹底獨立出來，而後經過AspectJ語法，編寫符合核心關注點要求的橫切關注點代碼，最後經過AspectJ編譯器，將這二者在後期結合起來。採用這種靜態織入技術，使得運用了AOP技術的系統在運行性能上未受到任何損失，由於它沒有利用反射技術或代理技術，而僅僅是程序的靜態擴展而已。然而這種源代碼生成方式實現的AOP雖然在性能上具有必定的優點，但它同時會給開發帶來必定的問題。例如代碼的後期修改會給系統帶來不可估量的影響。

Spring AOP是Spring框架中的一部分，但能夠做爲一個獨立的模塊單獨存在。Spring AOP實現AOP技術從本質上來說，是利用了JDK提供的動態代理技術。而從實際的實現方式來看，則是利用了IoC（Inversion of Control，反轉模式）機制，同時採用了AOP聯盟（AOP Alliance）的通用AOP接口。首先，Spring AOP經過xml配置文件配置了pointcut，並利用Interceptor（攔截機）做爲設定的觸發條件。Interceptor是由用戶自定義的，它至關因而AOP中的advice，但該Interceptor須要實現AOP聯盟的通用AOP接口，例如org.aopalliance.intercept.MethodInterceptor。最後定義一個Spring AOP ProxyFactory用於加載執行AOP組件，並利用IoC機制將advice注入到接口以及實現類中。

JBoss 4.0提供了AOP框架。與Spring同樣，這個框架可與JBoss應用服務器緊密結合，也能夠單獨運行在本身的應用中。JBoss AOP一樣須要Interceptor攔截器來完成對方法的攔截，它要求全部的Interceptor都必須實現org.jboss.aop.Interceptor接口。在這個接口中最重要的方法就是invoke()。該方法對元數據直接進行操做，並利用反射的原理去攔截方法的消息。Interceptor至關於AOP的advice，至於pointcut，則在xml配置文件中配置。能夠看出，Spring AOP和JBoss AOP在實現上屬於動態織入的方式，它們與AspectJ在實現上是迥然不一樣的兩種方式。

3.1.2.2 關於「Aspect（方面）」的區別

在對aspect的聲明上，可使用相似Java的代碼，註釋或xml。考慮一個經常使用的例子，對Account類的受權策略，若是以AOP技術來實現，運用不一樣的AOP工具，它們在方面聲明技術上的差別，是顯而易見的。

Aspect 中的方面聲明相似於 Java 語言中的類聲明，如圖3.1 所示。

圖3.1 AspectJ中的方面聲明

因爲 AspectJ 是 Java 語言語法和語義的擴展，因此它提供了本身的一套處理方面的關鍵字。除了包含字段和方法以外，AspectJ 的方面聲明還包含pointcut和advice成員。示例中的pointcut使用了修飾符（modifier）和通配符（wildcard）模式來表達「全部公共方法」。對賬戶的訪問，由 pointcut 參數提供。advice使用這個參數，而pointcut則用 this(account) 把它綁定。這樣作的效果，就是捕獲了正在執行的方法所隸屬的Account對象。不然，advice的主體與方法的主體類似。advice能夠包含認證代碼，或者就像在這個示例中同樣，能夠調用其餘方法。

JBoss AOP 基於 XML 的風格來聲明方面，如圖 3.2 所示。

圖3.2 JBoss AOP的方面聲明

在 XML 風格中，aspect、pointcut和advice的聲明都以 XML 形式表示的。advice的實現，用的是普通的 Java 方法，由JBoss AOP框架調用。pointcut和pointcut到advice的綁定都在方面中用XML註釋聲明。JBoss 沒有顯式地綁定 Account 參數，而是提供了對當前正在執行的對象的反射訪問，所以須要把類型轉換到對應的類型。JBoss AOP還能夠經過標籤的方式對方面進行聲明。標籤均以「@」字符開始，它的使用有點相似於.Net中的Attribute。

Spring AOP一樣是基於 XML 的風格來聲明方面，如圖3.3所示。

圖3.3 Spring AOP的方面聲明

與JBoss AOP相似，Spring的advice實現是帶有特殊參數的Java方法，由 Spring 框架調用。XML描述accountBean，Spring框架經過它訪問 Account 對象，包括通知使用的攔截器 advisor 及其匹配模式，還有應用到模式的向前（before） 通知。

因爲Spring AOP利用了IoC機制，所以比較JBoss AOP而言，在xml配置文件中提供了更加精細的配置。而構建、運行和配置 Spring AOP 方面的過程則與JBoss AOP基本相同，不過Spring AOP依賴的是Spring框架方便的、最小化的運行時配置，因此不須要獨立的啓動器。

3.1.2.3 語言機制的區別

    因爲實現機制和語法風格的不一樣，三種AOP工具在語言機制上也有很大的不一樣，如下從四個方面來描述AspectJ、JBossAOP和Spring AOP之間的區別。

（1）pointcut匹配和複合：AspectJ和 JBoss AOP 提供了相似的類型模式支持。它們都容許簽名方面的匹配，對於 Java 5 應用程序來講，這些匹配包括註釋和泛型。AspectJ提供了一種簡潔的引用多個類型的技術（例如 Account+ 表示賬戶的全部子類型）。全部的工具都支持通配符匹配。Spring AOP 還提供了對正則表達式的支持。雖然這看起來多是一個強大的優點，但仍是要指出其餘技術已經選擇了放棄正則表達式，好讓pointcut讀起來不是太難，同時不會存在潛在的損害。pointcut複合操做符基本上都是相同的。Spring AOP 不提供「非」操做，這個操做一般與沒有在 Spring AOP 鏈接點模型的容器（containment）鏈接點結合使用。

（2）advice形式：AspectJ 支持比其餘技術更多的advice形式，而 JBoss AOP 只支持一種advice形式。每種通知形式均可以表達成 around advice，因此 JBoss 的技術是無限的，並且它確實提供了額外的簡單性。很差的一面是它損失了簡潔性。另外，強迫advice去遵照普通的 Java 規則（就像註釋和 XML 風格作的那樣），在一些狀況下容易出問題，由於這些規則是爲方法設計的。AspectJ 擁有把被通知方法的異常「軟化」的能力，這頗有用，可是不符合方法異常檢測的標準語義。

（3）join point上下文：在 AspectJ中，經過指定和綁定pointcut參數訪問動態鏈接點的狀態，相似於在 Java 語言中聲明方法參數的技術（請參閱圖3.1）。這爲鏈接點上下文提供了靜態類型化的好處。JBoss AOP 和 Spring AOP 反射性地訪問鏈接點的狀態，這消除了在切入點表達式中參數綁定的複雜性，代價是參數靜態類型化。Java 程序員習慣了方法參數靜態類型化帶來的好處，同時還能夠從pointcut參數的靜態類型化獲得一樣的好處。因此，在 JBoss AOP 最近的發行版本中，有提供靜態類型化的「args」的計劃。

（4）擴展性：aspect的擴展性支持庫方面的部署，這樣能夠在往後爲特定程序將這些庫方面具體化。例如，一個方面庫能夠提供應用程序監視須要的所有邏輯和基礎設施。可是，要採用某個特定項目的庫，那麼庫使用的pointcut必須擴展成應用程序特定的join point。AspectJ 用抽象方面支持擴展性，抽象方面包含抽象的pointcut和具體的advice。擴展抽象方面的子方面必須具體化pointcut。JBoss AOP 使用了徹底不一樣的技術，沒有使用抽象切入點機制。擴展是經過生成aspect的子類、並在 XML 中或經過註釋定義新的advice綁定而實現的。pointcut到advice的顯式綁定爲JBoss AOP提供了顯著優點，從而能夠很容易地把方面擴展到新系統，無須要生成子類。

3.2 Java平臺下AOP主流工具研究

3.2.1 AsepctJ研究

AspectJ做爲Java編程語言擴展的AOP工具，使得咱們運用AOP技術可以像普通的Java編程那樣，特殊之處，僅在於咱們須要使用AspectJ提供的特殊語法。接下來，我將經過一些實例，介紹如何運用AspectJ實現AOP技術。

3.2.1.1 AspectJ語言特性

設定咱們的開發項目中須要應用到日誌記錄，根據前面介紹的AOP知識，咱們已經可以從這個需求中識別出橫切關注點——日誌記錄。所以，咱們須要定義關於「日誌記錄」的aspect：

public aspect AutoLog
{ 
    pointcut publicMethods() : execution(public * org.apache.cactus..*(..));
    pointcut logObjectCalls() : execution(* Logger.*(..));
    pointcut loggableCalls() : publicMethods() && ! logObjectCalls(); 

    before() : loggableCalls()
    {
      Logger.entry(thisJoinPoint.getSignature().toString());
    }
    after() : loggableCalls()
    {
      Logger.exit(thisJoinPoint.getSignature().toString());
    }
}

若是僅僅熟悉Java編程，會發現有不少關鍵字是Java語言中未曾包含的，它們均是AspectJ提供的。

分析上述的代碼，首先是aspect的聲明，它相似於Java中的類聲明，定義了一個aspect：AutoLog。在這個方面中分別包含了pointcut和advice。

pointcut共有三個：publicMethod、logObjectCalls和loggableCalls。publicMethod將選擇org.apache.cactus包中的全部公共（public）方法的執行。所謂「選擇」，就意味着它的join point爲其選擇的方法。當這些方法被調用時，就會執行pointcut的advice代碼。而在pointcut中，execution 是一個原始的 Pointcut（就象 int 是一種原始的 Java 類型）。它選擇與括號中定義的方法說明匹配的任何方法的執行。方法說明容許包含通配符。logObjectCalls的pointcut則選擇Logger 類中的全部方法的執行。第三個pointcut比較特殊，它使用&& !合併了前兩個 Pointcut，這意味着它選者了除Logger類中的公共方法之外， org.apache.cactus 中全部的公共方法。

advice在aspect中，被用來完成實際的日誌紀錄。advice有三種，分別爲before、after和around。如上述代碼中定義的advice：
before() : loggableCalls()
{
    Logger.entry(thisJoinPoint.getSignature().toString());
}

該advice的定義表示的含義是，若是org.apache.cactus中全部的公共方法（Logger類的公共方法除外）被執行，則在這些方法執行以前，須要先執行該advice定義的邏輯。

3.2.1.2 AspectJ的高級語言特性

在本文第二部分介紹AOP技術時，提到了橫切技術的分類。其中，靜態橫切技術可以擴展一個對象的結構。使用引入（Introduction），Aspect 能夠向類中添加新的方法和變量、聲明一個類實現一個接口或將檢查異常轉換爲未檢查異常（unchecked exception）。

3.2.1.2.1 向現有類添加變量和方法

假設您有一個表示持久存儲的數據緩存的對象。爲了測量數據的「更新程度」，您可能決定向該對象添加時間戳記字段，以便容易地檢測對象是否與後備存儲器同步。因爲對象表示業務數據，根據AOP的知識，咱們應該將這種機制性細節從對象中隔離。使用 AspectJ，能夠用以下代碼中所顯示的語法來向現有的類添加時間戳記：

public aspect Timestamp
{
    private long ValueObject.timestamp;
    public long ValueObject.getTimestamp()
    {
       return timestamp;
    }
    public void ValueObject.timestamp()
    {     
       this.timestamp = System.currentTimeMillis();
    }
}

經過introduction，咱們就很是方便的爲ValueObject類型添加了timestamp的變量和相關方法。除了必須限定在哪一個類上聲明引入的方法和成員變量之外，聲明引入的方法和成員變量幾乎與聲明常規類成員相同。

3.2.1.2.2實現多繼承功能

利用introduction，AspectJ容許向接口和類添加成員，也突破了Java語言只能單繼承的限制，容許程序按C++方式那樣實現多繼承。若是您但願上述的aspect Timestamp可以泛化 （generalize），以便可以對各類對象重用時間戳記代碼，能夠定義一個稱爲 TimestampedObject 的接口，並使用引入（Introduction）來將相同成員和變量添加到接口而不是添加到具體類中，以下所示:
public interface TimestampedObject
{
    long getTimestamp();
    void timestamp();
}
public aspect Timestamp
{
    private long TimestampedObject.timestamp;
    public long TimestampedObject.getTimestamp()
    {
        return timestamp;
    }
    public void TimestampedObject.timestamp()
    {
        this.timestamp = System.currentTimeMillis();
    }
}

Timestamp方面因爲在TimestampedObject接口中引入（introduction）了方法的實現，使得TimestampedObject接口改變其本質，成爲了一個特殊的類類型。特殊之處就在於一個已經繼承了一個類的類類型，經過AspectJ的語法，仍然能夠再次繼承TimestampedObject，這就間接地實現了類的多繼承。而這個特殊的AspectJ語法就是declare parents語法。declare parents和其它AspectJ 類型表達同樣，能夠同時應用於多個類型：
declare parents: ValueObject || BigValueObject implements TimestampedObject;

3.2.1.3 編譯器及工具支持

    要讓aspect可以正常工做，必須將aspect加入到它們要修改的代碼中去。這項工做由AspectJ提供的ajc編譯器完成。ajc 編譯器用來編譯類和 Aspect 代碼。ajc 既能夠做爲編譯器也能夠做爲預編譯器操做，生成有效的 .class 或 .java 文件，能夠在任何標準 Java 環境（添加一個小的運行時 JAR）中編譯和運行這些文件。

要使用 AspectJ 進行編譯，將須要顯式地指定但願在給定編譯中包含的源文件（Aspect 和類），ajc不象javac那樣簡單地爲相關導入模塊搜索類路徑。之因此這樣作，是由於標準 Java 應用程序中的每一個類都是相對分離的組件。爲了正確操做，一個類只要求其直接引用的類的存在。Aspect 表示跨越多個類的行爲的彙集。所以，須要將 AOP 程序做爲一個單元來編譯，而不能每次編譯一個類。

AspectJ 當前版本的一個重要限制是其編譯器只能將aspect加入到它擁有源代碼的代碼中。也就是說，不能使用ajc將Advice添加到預編譯類中。AspectJ 團隊認爲這個限制只是暫時的，AspectJ 網站承諾將來的版本（正式版 2.0）將容許字節碼的修改。

AspectJ發行版包含了幾種開發工具。這預示着 AspectJ 將有美好的前景，由於它代表了做者對這一部分的一個重要承諾，使 AspectJ 對於開發人員將是友好的。對於面向 Aspect 的系統工具支持尤爲重要，由於程序模塊可能受到它們所未知的模塊所影響。

隨 AspectJ 一塊兒發佈的一個最重要的工具是圖形結構瀏覽器，它展現了 Aspect 如何與其它系統組件交互。這個結構瀏覽器既能夠做爲流行的 IDE 的插件，也能夠做爲獨立的工具。圖3.4顯示了先前討論的日誌記錄示例的視圖。

圖3.4 AspectJ提供的「結構瀏覽器」工具

除告終構瀏覽器和核心編譯器以外，您還能夠從 AspectJ 網站下載一個 Aspect 支持的調試器、一個javadoc工具、一個Ant任務以及一個Emacs 插件。

3.2.2 JBoss AOP研究

JBoss AOP關於AOP的實現與AspectJ是兩種徹底不一樣的風格。因爲Java利用元數據來存儲有關類型、方法、字段的相關信息，所以，能夠經過Java提供的反射功能得到模塊相關的元數據，對方法進行攔截，並將被攔截的方法與aspect邏輯進行關聯。

3.2.2.1 攔截器（Interceptor）

在JBoss AOP中，是用攔截器來實現advice的。能夠自定義攔截器，攔截方法調用、構造函數調用以及對字段的訪問，但JBoss要求這些自定義的攔截器，必須實現org.jboss.aop.Interceptor接口：

public interface Interceptor
{
    public String getName();
    public InvocationResponse invoke(Invocation invocation) throws Throwable;
}

在JBoss　AOP中，被攔截的字段、構造器和方法均被轉化爲通用的invoke方法調用。方法的參數接收一個Invocation對象，而方法的返回值、字段的存取以及構造函數則被填入一個InvocationResponse對象。Invocation對象同時還驅動攔截鏈。下面咱們自定義一個攔截器，它可以攔截構造函數和方法的調用，並將跟蹤信息打印到控制檯上：
import org.jboss.aop.*;
import java.lang.reflect.*;

public class TracingInterceptor implements Interceptor
{
    public String getName()
    {
        return TracingInterceptor;
    }
    public InvocationResponse invoke(Invocation invocation) throws Throwable
    {
        String message = null;
        if (invocation.getType() == InvocationType.METHOD)
        {
            Method method = MethodInvocation.getMethod(invocation);
            message = method: + method.getName();
        }
        else
        {
            if (invocation.getType() == InvocationType.CONSTRUCTOR)
            {
                Constructor c = ConstructorInvocation.getConstructor(invocation);
                message = constructor: + c.toString();
            }
            else
            {
                // 不對字段做處理，太繁瑣；
                return invocation.invokeNext();
            }
            System.out.println(Entering + message);
        }
        // 繼續。調用真正的方法或者構造函數
        InvocationResponse rsp = invocation.invokeNext();
        System.out.println(Leaving + message);
        return rsp;
    }
}

在自定義的TracingInterceptor類中，invoke()方法對invocation的類型做判斷，以根據方法、構造函數和字段類型，分別做出不一樣的操做。而其中，invocation.invokeNext()則表示經過一個攔截鏈得到下一個invocation。

定義的攔截必須在xml文件配置，使其綁定到具體的類。這個定義即爲AOP中的切入點pointcut。例如具體的類爲BusinessObject，則該pointcut在xml中的定義以下：
<?xml version="1.0" encoding="UTF-8">
<aop>
    <interceptor-pointcut class="BusinessObject">
        <interceptors>
            <interceptor class="TracingInterceptor" />
        </interceptors>
    </interceptor-pointcut>
</aop>

上面的pointcut綁定TracingInterceptor到一個叫作BusinessObject的類。若是要將該Interceptor綁定到多個類，還能夠利用正則表達式。例如，若是你想綁定由JVM載入的類，類表達式將變爲 .*。若是你僅僅想跟蹤一個特定的包，那麼表達式將是bruce.zhang.mypackge.*。

當JBoss AOP獨立運行時，任何符合 META-INF/jboss-aop.xml模式的XML文件將被JBoss AOP 運行期程序載入。若是相關的路徑被包含在任何JAR或你的CLASSPATH目錄中，該XML文件將在啓動時，由JBoss AOP 運行期程序載入。

JBoss AOP還提供了過濾功能，能夠經過在xml文件中配置過濾的標誌，使一些特定的方法（包括字段的訪問）被過濾，從而再也不執行Interceptor的相關邏輯。例如，咱們要過濾BusinessObject類的全部get()和set()方法，以及main()方法，則能夠修改上述的xml文件：
<?xml version="1.0" encoding="UTF-8">
<aop>
    <class-metadata group="tracing" class=" BusinessObject ">
        <method name="(get.*)|(set.*)">
            <filter>true</filter>
        </method>
        <method name="main">
            <filter>true</filter>
        </method>
    </class-metadata>
</aop>

相應的，Interceptor代碼也應做相關的修改，使其可以識別配置文件中的filter屬性：
public class TracingInterceptor implements Interceptor
{
    ……//getName()方法略；
    public InvocationResponse invoke(Invocation invocation) throws Throwable
    {
        String filter=(String)invocation.getMetaData(tracing, filter);
        if (filter != null && filter.equals(true))
            return invocation.invokeNext();
        ……//後面的代碼略；
    }
}

3.2.2.2 引入（Introduction）

JBoss AOP一樣提供introduction功能，經過它，就能夠爲現有的類引入第三方接口或類的API了。例如，咱們能夠爲具體的類如BusinessObject提供Tracing的開關，使得BusinessObject對象可以根據具體的狀況打開或關閉aspect的Tracing功能。爲實現該功能，能夠定義一個Tracing接口：
public interface Tracing
{
    void enableTracing();
    void disableTracing();
}

接下來須要定義一個混合類，它實現了接口Tracing。當BusinessObject類被實例化時，該混合類的實例就會被綁定到BusinessObject上。實現方法以下：
import org.jboss.aop.Advised;

public class TracingMixin implements Tracing
{
    Advised advised;

    Public TracingMixin(Object obj)
    {
        this.advised = (Advised)obj;
    }
    public void enableTracing()
    {
        advised._getInstanceAdvisor().getMetaData().addMetaData("tracing", "filter", true);
    }
    public void disableTracing()
    {
        advised._getInstanceAdvisor().getMetaData().addMetaData("tracing", "filter", false);
    }
}

enableTracing()方法將filter屬性綁定到對象實例。disableTracing()方法做一樣的事，可是將filter屬性設置爲false。

定義了Tracing接口和實現了該接口的混合類後，就能夠在xml文件中定義一個pointcut，強制BusinessObject類實現Tracing接口：
<?xml version="1.0" encoding="UTF-8">
<aop>
    <introduction-pointcut class="BusinessObject">
        <mixin>
            <interfaces>Tracing</interfaces>
            <class>TracingMixin</class>
            <construction>new TracingMixin(this)</construction>
        </mixin>
    </introduction-pointcut>
</aop>

注意xml文件中的標籤，它表明的含義是當BusinessObject對象被實例化時，將執行該標籤內的代碼。以本例而言，當建立BusinessObject對象時，一個TracingMixin類的實例將被建立。任何單行的Java代碼均可以放到標籤中。

經過「引入（introduction）」功能，在處理BusinessObject對象時，就能夠視其爲Tracing接口類型而進行操做了，以下的示例：

public class BusinessObject
{
    public BusinessObject () {}
    public void helloWorld() { System.out.println(Hello World!); }

    public static void main(String[] args)
    {
        BusinessObject bo = new BusinessObject ();
        Tracing trace = (Tracing)this;
        bo.helloWorld();
       
        System.out.println("Turn off tracing.");
        trace.disableTracing();
        bo.helloWorld();
       
        System.out.println("Turn on tracing.");
        trace.enableTracing();
        bo.helloWorld();
    }
}

注意以下代碼：
Tracing trace = (Tracing)this;

此時this表明的即爲BusinessObject，從Java代碼的角度來看，因爲BusinessObject並無實現Tracing接口，所以這行代碼所示的顯式轉換爲Tracing類型是不成功的。但經過「引入」功能，使得BusinessObject經過混合類，實現了Tracing接口，從而使得如上的代碼可以順利執行。隱含的意義就是，咱們沒有修改BusinessObject的定義，而是經過AOP技術，爲BusinessObject擴展實現了第三方提供的接口Tracing。

3.2.3 Spring AOP研究

Spring AOP使用純Java實現，不須要特別的編譯過程，也不須要控制類裝載層次。與JBoss AOP相同，它仍然利用了攔截器完成對方法的攔截。然而，Spring AOP實現AOP的主要技術卻主要來自於AOP聯盟，如攔截器應實現org.aopalliance.intercept.MethodInterceptor 接口，而全部advice必須實現org.aopalliance.aop.Advice標籤接口。此外，Spring實現AOP的目標也不一樣於其餘大部分AOP框架，它的目標不是提供及其完善的AOP實現，而是提供一個和Spring IoC緊密整合的AOP實現，幫助解決企業應用 中的常見問題。所以，Spring AOP的功能一般是和Spring IoC容器聯合使用的。AOP Advice是用普通的bean定義語法來定義的，Advice和pointcut自己由Spring IoC 管理。這是一個重要的其餘AOP實現的區別。

3.2.3.1 切入點（pointcut）

Spring的切入點模型可以使pointcut獨立於advice類型被重用。一樣的pointcut有可能接受不一樣的advice。將Pointcut接口分紅兩個部分有利於重用類和方法的匹配部分，而且組合細粒度的操做（如和另外一個方法匹配器執行一個「並」的操做）。

在Spring的切入點中，org.springframework.aop.Pointcut接口是重要的接口，它用來指定通知到特定的類和方法目標。完整的接口定義以下:
public interface Pointcut
{
    ClassFilter getClassFilter();
    MethodMatcher getMethodMatcher();
}

ClassFilte類型也是一個接口，該接口被用來將切入點限制到一個給定的目標類的集合。 若是matches()永遠返回true，全部的目標類都將被匹配。
public interface ClassFilter
{
    boolean matches(Class clazz);
}

MethodMatcher接口一般更加劇要。完整的接口定義以下：
public interface MethodMatcher
{
    boolean matches(Method m, Class targetClass);
    boolean matches(Method m, Class targetClass, Object[] args);
    boolean isRuntime();
}

matches(Method, Class) 方法被用來測試這個切入點是否匹配目標類的給定方法。這個測試能夠在AOP代理建立的時候執行，避免在全部方法調用時都須要進行 測試。若是2個參數的matches()方法對某個方法返回true，而且MethodMatcher的isRuntime()也返回true，那麼3個參數的matches()方法將在每次方法調用的時候被調用。這使切入點可以在目標advice被執行以前當即查看傳遞給方法調用的參數。因爲大部分MethodMatcher都是靜態的，意味着isRuntime()方法會返回false。此種狀況下，3個參數的matches()方法永遠不會被調用。

Spring AOP提供了幾個實用的切入點實現，其中較爲經常使用的是正則表達式切入點：org.springframework.aop.support.RegexpMethodPointcut，它使用Perl 5的正則表達式的語法。使用這個類你能夠定義一個模式的列表。若是任何一個匹配，那個切入點將被計算成 true。用法以下：
<bean id="settersAndAbsquatulatePointcut"
    class="org.springframework.aop.support.RegexpMethodPointcut">
    <property name="patterns">
        <list>
            <value>.*get.*</value>
            <value>.*absquatulate</value>
        </list>
    </property>
</bean>

不過，更多狀況下是直接使用RegexpMethodPointcut一個實用子類： RegexpMethodPointcutAdvisor。它容許咱們同時引用一個advice（在Spring AOP中，advice能夠是攔截器，也能夠是before advice，throws advice等)。這就簡化了bean的裝配，由於一個bean能夠同時看成pointcut和advice，以下所示：
<bean id="myPointcutAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
    <property name="advice">
        <ref local="MyInterceptor" />
    </property>
    <property name="patterns">
        <list>
            <value>.*save.*</value>
            <value>.*do.*</value>
        </list>
    </property>
</bean>

注意配置文件中的myPointcutAdvisor，在Spring AOP中，一個advisor就是一個aspect完整的模塊化表示。經過advisor，能夠將pointcut和advice（在此處即爲MyInterceptor）綁定起來。

3.2.3.2 通知（advice）

Spring AOP的advice能夠跨越多個被advice對象共享，或者每一個被advice對象有本身的advice。要實現advice，最簡單的作法就是定義一個攔截器（Interceptor）。它採用了AOP聯盟（AOP Alliance）的通用AOP接口（接口定義爲aopalliance.jar）。要實現advice，須要實現aopalliance.jar中定義的MethodInterceptor接口。

例如，咱們定義了一個業務對象接口BusinessObject及其實現類BusinessObjectImpl，該業務對象可以存儲數據，其定義以下：
public interface BusinessObject
{
    public void save();
}
public class BusinessObjectImpl implements BusinessObject
{
    public void save()
    {
         System.out.println("saving domain object......");
    }
}

如今須要爲業務對象BusinessObject的Save()方法，提供Lock機制。根據Spring AOP的實現方式，咱們能夠定義一個LockInterceptor來實現MethodInterceptor接口：
import org.aopalliance.intercept.MethodInterceptor;
import org.aopalliance.intercept.MethodInvocation;

public class LockInterceptor implements MethodInterceptor
{
    public Object invoke(MethodInvocation invocation) throws Throwable
    {
        // TODO Auto-generated method stub
        lock();
        Object ret= invocation.proceed();
        unlock();
        return ret;
    }
    private void lock()
    {
        System.out.println("lock domain object...");
    }
    private void unlock()
    {
        System.out.println("unlock domain object...");
    }
}

爲將interceptor與具體的advice綁定起來，須要在配置文件中配置bean：
&lt;bean id="MyInterceptor" class="test.aop.spring.LockInterceptor"/&gt;

3.2.3.3 AOP代理與IoC容器

因爲Spring中提供了IoC容器（例如BeanFactory），所以咱們能夠經過Ioc機制，利用ProxyFactoryBean來建立AOP代理。ProxyFactoryBean和其餘Spring的 FactoryBean實現同樣，引入一個間接的層次。若是你定義一個名字爲foo的ProxyFactoryBean，引用foo的對象所看到的不是ProxyFactoryBean實例自己，而是由實現ProxyFactoryBean的類的 getObject()方法所建立的對象。這個方法將建立一個包裝了目標對象 的AOP代理。

AOP代理利用的是Java的動態代理技術，經過它就能夠加載並執行AOP組件。同時，還須要經過IoC的方式將advice注入到接口以及其實現類。之前面的業務對象BusinessObject爲例，在xml配置文件中的配置以下：
<bean id="myAOPProxy" class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="proxyInterfaces">
       <value>test.aop.spring.BusinessObject</value>
    </property>
    <property name="target">
       <ref local="impl" />
    </property>
    <property name="interceptorNames">
       <value>myPointcutAdvisor</value>
    </property>
</bean>
<bean id="impl" class="test.aop.spring.BusinessObjectImpl"/>

經過上述對pointcut、advice、advisor和AOP代理的配置，咱們就能夠輕易地在Spring中實現AOP，例如：
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class App
{
    private BusinessObject bo = null;
    public static void main(String[] args)
    {
        ApplicationContext ctx=new FileSystemXmlApplicationContext("Bean.xml");
        bo= (BusinessObject) ctx.getBean("myAOPProxy");
        bo.save();
    }
}

首先，經過AOP代理得到BusinessObject對象。當調用BusinessObject對象的save()方法時，攔截器LockInterceptor根據RegexpMethodPointcutAdvisor配置的pointcut和advice之間的關係，斷定該方法的調用爲join point，從而攔截該方法調用，並注入advice的執行邏輯，即lock()和unlock()，最終實現了AOP。

3.2.3.4 引入（introduction）

在Spring AOP中，將introduction看成advice來處理。與通常的advice同樣，introduction advice至關於一種特殊類型的攔截通知，須要實現IntroductionAdvisor和IntroductionInterceptor接口，而IntroductionInterceptor接口繼承自MethodInterceptor：
public interface IntroductionInterceptor extends MethodInterceptor
{
    boolean implementsInterface(Class intf);
}

Introduction通知不能被用於任何pointcut，由於它只能做用於類層次上，而不是方法。咱們能夠只用InterceptionIntroductionAdvisor來實現導入通知，它有下面的方法：
public interface InterceptionIntroductionAdvisor extends InterceptionAdvisor
{
    ClassFilter getClassFilter();
    IntroductionInterceptor getIntroductionInterceptor();
    Class[] getInterfaces();
}

接下來，我以JBoss AOP一節中的例子來講明introduction在Spring AOP中的應用。咱們的目標仍然是爲一個已有的業務對象引入第三方接口Tracing：
public interface Tracing
{
    void enableTracing();
    void disableTracing();
    boolean enabled();
}

首先，咱們須要一個作大量轉化的IntroductionInterceptor。在這裏，咱們繼承 org.springframework.aop.support.DelegatingIntroductionInterceptor 實現類。固然咱們能夠直接實現IntroductionInterceptor接口，可是大多數狀況下 DelegatingIntroductionInterceptor是最合適的。

DelegatingIntroductionInterceptor的設計是將introduction委託到真正實現introduction接口的接口，隱藏完成這些工做的攔截器。委託可使用構造方法參數設置到任何對象中；默認的委託就是本身（當無參數的構造方法被使用時）。這樣在下面的例子裏，委託是DelegatingIntroductionInterceptor的子類 TracingMixin。給定一個委託（默認是自身）的 DelegatingIntroductionInterceptor實例尋找被這個委託（而不是IntroductionInterceptor）實現的全部接口，並支持它們中任何一個導入。子類如TracingMixi也可能調用suppressInterflace(Class intf) 方法來隱藏不該暴露的接口。然而，無論IntroductionInterceptor 準備支持多少接口，IntroductionAdvisor將控制哪一個接口將被實際暴露。一個導入的接口將隱藏目標的同一個接口的全部實現。

這樣，TracingMixin繼承DelegatingIntroductionInterceptor並本身實現接口Tracing。父類自動選擇支持introduction的Tracing，因此咱們不須要指定它。用這種方法咱們能夠導入任意數量的接口。
public class TracingMixin extends DelegatingIntroductionInterceptor implements Tracing
{
    private boolean enabled;
    public void enableTracing ()
    {
        this.enabled = true;
    }

    public void disableTracing ()
    {
        this. enabled = false;
    }

    public boolean enabled()
    {
        return this.enabled;
    }
    public Object invoke(MethodInvocation invocation) throws Throwable
    {      
        return super.invoke(invocation);
    }
}

一般不要須要改寫invoke()方法：實現DelegatingIntroductionInterceptor就足夠了，若是是引入的方法，DelegatingIntroductionInterceptor實現會調用委託方法， 不然繼續沿着鏈接點處理。

所需的introduction advisor是很簡單的。只需保存一個獨立的TracingMixin實例，並指定導入的接口，在這裏就是Tracing。此時，TracingMixin沒有相關配置，因此咱們簡單地使用new來建立它。

public class TracingMixinAdvisor extends DefaultIntroductionAdvisor
{
    public TracingMixinAdvisor() {
        super(new TracingMixin(),Tracing.class);
    }
}

咱們能夠很是簡單地使用這個advisor。它不須要任何配置。（可是，有一點是必要的：就是不可能在沒有IntroductionAdvisor 的狀況下使用IntroductionInterceptor。） 和引入同樣，一般 advisor必須是針對每一個實例的，而且是有狀態的。咱們會有不一樣的TracingMixinAdvisor。每一個被通知對象，會有不一樣的TracingMixin。advisor組成了被通知對象的狀態的一部分。

在Spring中，Spring AOP的核心API已經基本穩定了。和Spring的其它部分同樣， AOP框架是模塊化的，在保留基礎設計的同時提供擴展。在Spring 1.1到1.2階段有不少地方可能會有所提升，可是這些地方也保留了向後兼容性。它們是：

（一）性能的提升：AOP代理的建立由工廠經過策略接口處理。所以可以支持額外的AOP 代理類型而不影響用戶代碼或核心實現。（二）更具表達力的pointcut：Spring目前提供了一個具備表達力的切入點接口，同時添加了更多的切入點實現。Spring正在考慮提供一個簡單但具備強大表達式語言的實現。