摘要

　　快速發展的開發人員社區、對各種后端技術（包括JMS、JTA、JDO、Hibernate、iBATIS等等）的支持，以及（更為重要的）非侵入性的輕量級IoC容器和內置的AOP運行時，這些因素使得SPRing Framework對于J2EE應用程序開發十分具有吸引力。Spring托管的組件（POJO）可以與EJB共存，并答應使用AOP方法來處理企業應用程序中的橫切方面——從監控和審計、緩存及應用程序級的安全性開始，直到處理特定于應用程序的業務需求。

　　本文將向您介紹Spring的AOP框架在J2EE應用程序中的實際應用。

簡介

　　J2EE技術為實現服務器端和中間件應用程序提供了堅實的基礎。J2EE容器（比如BEA WebLogic Server）可以治理系統級的元素，包括應用程序生命周期、安全性、事務、遠程控制和并發性，而且它可以保證為JDBC、JMS和JTA之類的常見服務提供支持。然而，J2EE的龐大和復雜性使開發和測試變得異常困難。傳統的J2EE應用程序通常嚴重依靠于通過容器的JNDI才可用的服務。這意味著需要大量直接的JNDI查找，或者要使用Service Locator模式，后者稍微有所改進。這種架構提高了組件之間的耦合度，并使得單獨測試某個組件成為幾乎不可能實現的事情。您可以閱讀Spring Framework創建者所撰寫的J2EE Development without EJB一書，其中深入分析了這種架構的缺陷。

　　借助于Spring Framework，可以將使用無格式java對象實現的業務邏輯與傳統的J2EE基礎架構連接起來，同時極大地減少了訪問J2EE組件和服務所需的代碼量。基于這一點，可以把傳統的OO設計與正交的AOP組件化結合在一起。本文稍后將會演示如何重構J2EE組件以利用Spring托管的Java對象，然后應用一種AOP方法來實現新特性，從而維護良好的組件獨立性和可測試性。

　　與其他AOP工具相比，Spring提供了AOP功能中的一個有限子集。它的目標是緊密地集成AOP實現與Spring IoC容器，從而幫助解決常見的應用問題。該集成是以非侵入性的方式完成的，它答應在同一個應用程序中混合使用Spring AOP和表現力更強的框架，包括aspectJ。Spring AOP使用無格式Java類，不要求非凡的編譯過程、控制類裝載器層次結構或更改部署配置，而是使用Proxy模式向應該由Spring IoC容器托管的目標對象應用通知。

　　可以根據具體情況在兩種類型的代理之間進行選擇：

• 第一類代理基于Java動態代理，只適用于接口。它是一種標準的Java特性，可提供卓越的性能。
• 第二類代理可用于目標對象沒有實現任何接口的場景，而且這類接口不能被引入（例如，對于遺留代碼的情況）。它基于使用CGLIB庫的運行時字節碼生成。

　　對于所代理的對象，Spring答應使用靜態的（方法匹配基于確切名稱或正則表達式，或者是注釋驅動的）或動態的（匹配是在運行時進行的，包括cflow切入點類型）切入點定義指派特定的通知，而每個切入點可以與一條或多條通知關聯在一起。所支持的通知類型有幾種：環繞通知（around advice），前通知（before advice），返回后通知（after returning advice），拋出異常后通知（after throwing advice），以及引入通知（introdUCtion advice）。本文稍后將給出環繞通知的一個例子。想要了解更具體的信息，可以參考Spring AOP框架文檔。

　　正如先前提到的那樣，只可以通知由Spring IoC容器托管的目標對象。然而，在J2EE應用程序中，組件的生命周期是由應用服務器托管的，而且根據集成類型，可以使用一種常見的端點類型把J2EE應用程序組件公開給遠程或本地的客戶端：

• 無狀態的、有狀態的或實體bean，本地的或遠程的（基于RMI-IIOP）
• 監聽本地或外部JMS隊列和主題或入站JCA端點的消息驅動bean(MDB)
• Servlet(包括Struts或其他終端用戶UI框架、xml-RPC和基于SOAP的接口)

圖 1.常見的端點類型

　　要在這些端點上使用Spring的AOP框架，必須把所有的業務邏輯轉移到Spring托管的bean中，然后使用服務器托管的組件來委托調用，或者定義事務劃分和安全上下文。雖然本文不討論事務方面的問題，但是可以在“參考資料”部分中找到相關文章。