為什么要區分J2EE容器和J2EE應用系統？
我們知道，J2EE應用系統只有部署在J2EE容器中才能運行，那么為什么劃分為J2EE容器和J2EE應用系統？ 通過對J2EE容器運
行機
制的分析，我們可以發現：實際上J2EE容器分離了一般應用系統的一些通用功能，例如事務機制、安全機制以及對象池或線程池等性能優化機制。
這些功能機制是每個應用系統幾乎都需要的，因此可以從具體應用系統中分離出來，形成一個通用的框架平臺，而且，這些功能機制的設計開發有一定難度，同時運行的穩定性和快速性都非常重要，必須經過長時間調試和運行經驗積累而成，因此，形成了專門的J2EE容器服務器產品，如Tomcat JBoss、Websphere、WebLogic等。
從J2EE系統劃分為J2EE容器和J2EE應用系統兩個方面，我們已經看到一種分散關注的思路（separation of concerns）。
分散關注
將通用需求功能從不相關類之中分離出來；同時，能夠使得很多類共享一個行為，一旦行為發生變化，不必修改很多類，只要修改這個行為就可以。
AOP就是這種實現分散關注的編程方法，它將“關注”封裝在“方面”中。
AOP是什么？
AOP是OOP的延續，是Aspect Oriented Programming的縮寫，意思是
面向方面編程
。AOP實際是GoF設計模式的延續，設計模式孜孜不倦追求的是調用者和被調用者之間的解耦，AOP可以說也是這種目標的一種實現。
舉例：假設有在一個應用系統中，有一個共享的數據必須被并發同時訪問，首先，將這個數據封裝在數據對象中，稱為Data Class，同時，將有多個訪問類，專門用于在同一時刻訪問這同一個數據對象。
為了完成上述并發訪問同一資源的功能，需要引入鎖Lock的概念，也就是說，某個時刻，當有一個訪問類訪問這個數據對象時，這個數據對象必須上鎖Locked，用完后就立即
解鎖
unLocked，再供其它訪問類訪問。
使用傳統的編程習慣，我們會創建一個
抽象類
，所有的訪問類繼承這個抽象父類，如下：
abstract class Worker{
abstract void locked();
abstract void accessDataObject();
abstract void unlocked();
}
|
缺點：
accessDataObject()方法需要有“鎖”狀態之類的相關代碼。Java只提供了單繼承，因此具體訪問類只能繼承這個父類，如果具體訪問類還要繼承其它父類，比如另外一個如Worker的父類，將無法方便實現。重用被打折扣，具體訪問類因為也包含“鎖”狀態之類的相關代碼，只能被重用在相關有“鎖”的場合，重用范圍很窄。
仔細研究這個應用的“鎖”，它其實有下列特性：
“鎖”功能不是具體訪問類的首要或主要功能，訪問類主要功能是訪問數據對象，例如讀取數據或更改動作。
“鎖”行為其實是和具體訪問類的主要功能可以獨立、區分開來的。
“鎖”功能其實是這個系統的一個縱向切面，涉及許多類、許多類的方法。如下圖：
因此，一個新的程序結構應該是關注系統的縱向切面，例如這個應用的“鎖”功能，這個新的程序結構就是aspect（方面）在這個應用中，“鎖”方面（aspect）應該有以下職責：
提供一些必備的功能，對被訪問對象實現
加鎖
或解鎖功能。以保證所有在修改數據對象的操作之前能夠調用lock()加鎖，在它使用完成后，調用unlock()解鎖。
AOP有必要嗎？
當然，上述應用范例在沒有使用AOP情況下，也得到了解決，例如JBoss 3.XXX也提供了上述應用功能，但是沒有使用AOP。
但是，使用AOP可以讓我們從一個更高的抽象概念來理解軟件系統，AOP也許提供一種有價值的工具。可以這么說：因為使用AOP結構，現在JBoss 4.0的源碼要比JBoss 3.X容易理解多了，這對于一個大型復雜系統來說是非常重要的。
從另外一個方面說，好像不是所有的人都需要關心AOP，它可能是一種架構設計的選擇，如果選擇J2EE系統，AOP關注的上述通用方面都已經被J2EE容器實現了，J2EE應用系統開發者可能需要更多地關注行業應用方面aspect。
AOP具體實現
AOP是一個概念，并沒有設定具體語言的實現，它能克服那些只有單繼承特性語言的缺點（如Java），目前AOP具體實現有以下幾個項目：
AspectJ (TM)： 創建于Xerox PARC. 有近十年歷史，技術成熟。
缺點：過于復雜；破壞封裝；需要專門的Java編譯器。
動態AOP：使用JDK的動態代理API或字節碼Bytecode處理技術。
基于動態代理API的具體項目有：
JBoss 4.0 JBoss 4.0服務器
基于字節碼的項目有：
aspectwerkz
spring
來源：http://dev.yesky.com/349/2155349.shtml
馬嘉楠
jianan.ma@gmail.com
posted on 2006-08-28 17:38
馬嘉楠 閱讀(302)
評論(0) 編輯 收藏