AOP下的權(quán)限控制實現(xiàn)

摘要面向方面的編程(AOP)是一種新的編程技術(shù)，它彌補了面向?qū)ο蟮木幊?OOP)在跨越模塊行為上的不足。AOP引進了Aspect，它將影響多個類的行為封裝到一個可重用模塊中，它允許程序員對橫切關(guān)注點進行模塊化，從而消除了OOP引起的代碼混亂和分散問題，增強了系統(tǒng)的可維護性和代碼的重用性。本文分析傳統(tǒng)權(quán)限控制的實現(xiàn)方法，并研究了在AOP下權(quán)限控制的實現(xiàn)方法。關(guān)鍵詞AOP；橫切關(guān)注點；設(shè)計模式；權(quán)限控制

1OOP應(yīng)用開發(fā)面臨的問題面向?qū)ο蠹夹g(shù)很好地解決了軟件系統(tǒng)中角色劃分的問題。借助于面向?qū)ο蟮姆治?、設(shè)計和實現(xiàn)技術(shù)，開發(fā)者可以將問題領(lǐng)域的“名詞”轉(zhuǎn)換成軟件系統(tǒng)中的對象，從而很自然地完成從問題到軟件的轉(zhuǎn)換。但是，問題領(lǐng)域的某些需求卻偏偏不是用這樣的“名詞”來描述的。比如遇到這樣的問題：需要對系統(tǒng)中的某些方法進行權(quán)限檢驗，這種需要權(quán)限檢驗的方法散布在40多個類中。面對這種需求，應(yīng)該怎么辦呢？最直接的辦法就是：創(chuàng)建一個起類，將權(quán)限檢驗的功能放在其中，并讓所有需要權(quán)限檢驗的類繼承這個起類．如果這個需求是后期提出的．需要修改的地方就會分散在40多個文件中。這樣大的修改量，無疑會增加出錯的幾率，并且加大系統(tǒng)維護的難度。人們認(rèn)識到，傳統(tǒng)的程序經(jīng)常表現(xiàn)出一些不能自然地適合單個程序模塊或者幾個緊密相關(guān)的程序模塊的行為例如權(quán)限檢驗、日志記錄、對上下文敏感的錯誤處理、性能優(yōu)化以及設(shè)計模式等等、我們將這種行為稱為“橫切關(guān)注點”，因為它跨越了給定編程模型中的典型職責(zé)界限。如果使用過用于橫切關(guān)注點的代碼，您就會知道缺乏模塊性所帶來的問題。因為橫切行為的實現(xiàn)是分散的，開發(fā)人員發(fā)現(xiàn)這種行為難以作邏輯思維、實現(xiàn)和更改。

2AOP的基本思想AOP是AspectOrientedProgramming的縮寫，意思是面向方面編程，一種新興的編程技術(shù)。AOP實際是GoF設(shè)計模式的延續(xù)，設(shè)計模式孜孜不倦追求的是調(diào)用者和被調(diào)用者之間的解耦，AOP可以說也是這種目標(biāo)的一種實現(xiàn)。它可以解決OOP和過程化方法不能夠很好解決的橫切問題，如：事務(wù)、安全、日志等橫切關(guān)注。當(dāng)未來系統(tǒng)變得越來越復(fù)雜，橫切關(guān)注點就成為一個大問題的時候，AOP就可以很輕松的解決橫切關(guān)注點這個問題。

圖1把模塊作為一批關(guān)注點來實現(xiàn)通常，為滿足整個企業(yè)應(yīng)用某方面得需求，開發(fā)者需要整理出系統(tǒng)得關(guān)注點。圖1形象地描述了關(guān)注點，它能夠從AOPAspect角度看待系統(tǒng)。比如，持久化、日志、應(yīng)用的業(yè)務(wù)邏輯通常被認(rèn)為是應(yīng)用需要解決的問題。因此，他們通常作為關(guān)注點看待。從整個系統(tǒng)角度考慮，它往往是由大量的關(guān)注點構(gòu)成的。我們把AOP看作是OOP的延續(xù)，而不是競爭對手。OOP在通常的場合下工作得很好，但在特定的領(lǐng)域里卻有所欠缺：舉例來說，如果我們必須為多個對象和方法應(yīng)用相同的事務(wù)行為，我們需要將同樣的代碼剪切/粘貼到每一個方法里。AOP讓我們可以把這類問題封裝到方面中，從而更好地實現(xiàn)模塊化。AOP定義了“切入點”的概念，讓開發(fā)者可以從另一個角度來思考程序的結(jié)構(gòu)，從而彌補了OOP的某些缺陷：如果需要對一組方法施加橫切的行為，就應(yīng)該攔截這些方法。在J2EE應(yīng)用開發(fā)中，我們主要用到AOP的攔截能力，它為我們提供了“在任何對象的方法調(diào)用前/后加入自定義行為”的能力，這使得我們可以處理企業(yè)應(yīng)用中的橫切關(guān)注點，并且仍然保持強類型。

3權(quán)限控制的應(yīng)用程序?qū)崿F(xiàn)對于權(quán)限管理的做法，在WEB實現(xiàn)上，有以下幾種：⑴利用Filter，對所有進入的URI進行解析，并取得當(dāng)時Session中的User信息，然后通過RBAC的機制，將此鏈接需要的權(quán)限與用戶擁有的權(quán)限進行比較，然后進行相應(yīng)的處理。這種做法有很多好處：簡單，容易實現(xiàn)，并且對系統(tǒng)侵入性也不強。這里URL就是RBAC中的資源了。這樣做的缺點是所有對數(shù)據(jù)的操作必須通過URL來體現(xiàn)，這一點在現(xiàn)代的程序中不太好實現(xiàn)。如果采用Struts,XWork或者Tapestry，采用同一個URL進行處理多項任務(wù)已不是什么稀奇的事。⑵利用一個BaseServlet(Servlet+Jsp經(jīng)典模式)或者BaseAction(Struts模式)或者BasePage(Tapestry模式)或者BaseController(SpringMVC模式)，對所有的請求先進行過濾進行權(quán)限操作，然后再處理。稍微看一下就知道這種模式跟Filter并無本質(zhì)不同。優(yōu)缺點同上。那么，如果要實現(xiàn)更為細(xì)致的權(quán)限操作，精確到某個方法的權(quán)限，典型的做法publicsomeFunciton(){

//權(quán)限判斷

Useruser=();

if(()){

//dothebusinessmethod

//...

}else{

thrownewPermissionDeniedException();

}

}這種做法能夠?qū)?quán)限的粒度控制到具體的業(yè)務(wù)方法，因此它的控制能力應(yīng)該是強大的。可以看到，權(quán)限判斷部分對于每個方法幾乎是獨立的。這種在具體功能前加入權(quán)限操作檢驗的實現(xiàn)方式有很多缺點：

⑴每個功能類都需要相應(yīng)的權(quán)限檢驗代碼，將程序功能和權(quán)限檢驗混淆在一起，存在緊密的耦合性，擴展修改難度大。

⑵以代理模式為每個功能類實現(xiàn)一個相應(yīng)的代理類，雖然解耦了程序功能和權(quán)限檢驗，但是，從某個角色的權(quán)限檢驗這個切面考慮，涉及具體Proxy類太多，擴展修改難度大。

4權(quán)限控制的J2EE容器實現(xiàn)在AOP概念沒有誕生前，J2EE規(guī)范已經(jīng)提供了關(guān)于權(quán)限控制的容器實現(xiàn)標(biāo)準(zhǔn)，這種變遷結(jié)果如下圖所示：圖2權(quán)限控制的J2EE容器實現(xiàn)原來需要每個應(yīng)用程序?qū)崿F(xiàn)的權(quán)限Proxy轉(zhuǎn)為整個容器的Proxy實現(xiàn)，其中以后的動態(tài)代理API為這種轉(zhuǎn)換實現(xiàn)提供了技術(shù)保證。非常明顯，通過容器實現(xiàn)權(quán)限控制驗證可以大大簡化應(yīng)用程序的設(shè)計，分離了應(yīng)用系統(tǒng)的權(quán)限關(guān)注，將權(quán)限控制變成了對J2EE容器服務(wù)器的配置工作。

其實，容器的權(quán)限實現(xiàn)也是一種從一個側(cè)面來解決問題方式，AOP概念誕生后，權(quán)限控制實現(xiàn)由此也帶來了兩個方向的變化：

⑴J2EE容器級別的權(quán)限實現(xiàn)，也就是容器自身的權(quán)限實現(xiàn)。

⑵J2EE應(yīng)用程序級別的權(quán)限實現(xiàn)。權(quán)限控制在容器級別實現(xiàn)似乎使得J2EE開發(fā)者感覺沒有靈活性和可擴展性，其實象JBoss這樣的J2EE容器，由于引入了AOP概念，使得J2EE開發(fā)者在自己的應(yīng)用系統(tǒng)中能夠直接操縱容器的一些行為。容器和應(yīng)用系統(tǒng)由于AOP引入的Aspect切面，變得可以成為一體了。對于J2EE應(yīng)用系統(tǒng)開發(fā)者，能夠做到上述境界，必須的條件是對JBoss之類J2EE容器必須有足夠的了解，因為這些方式并不是J2EE標(biāo)準(zhǔn)，有可能在移植到新的J2EE容器，這些知識和投入變得無用。很顯然，使用AOP實現(xiàn)J2EE應(yīng)用系統(tǒng)級別的權(quán)限控制，是解決上述移植風(fēng)險的一個主要方法，但是帶來的缺點是必須親自從零開始做起，耗費時間不會很短。

5AOP下的權(quán)限控制實現(xiàn)有了AOP，新的業(yè)務(wù)方法可以這樣寫：publicsomeFunciton(){

//dothebusinessmethod

//...

}沒有了額外的權(quán)限操作，這個業(yè)務(wù)方法看起來那么清晰自然。將對權(quán)限的操作作為一個Advice，并將Advisor關(guān)注到所有的業(yè)務(wù)方法，然后，剩下的事情就由RBAC以及AOP來完成了。通過這樣的分離，縱向的一個業(yè)務(wù)方法被分割為一個更為自然的業(yè)務(wù)方法和一個關(guān)注點。這個關(guān)注點寫法可能publicclassPermissionCheckAdviceimplementsMethodBeforeAdvice{

publicvoidbefore(Methodarg0,Object[]arg1,Objectarg2)throwsThrowable{

//權(quán)限判斷

if(!().getUser().canExcute(this,arg0)){

throwsnewPermissionDeniedException();

}

}

}可能有個問題：如何取得context或者當(dāng)時上下文環(huán)境的User呢？答案是使用IoC，將上下文環(huán)境或者User作為參數(shù)反向傳入到邏輯方法中。當(dāng)然，在傳入之前，這些變量是需要初始化的。這個初始化工作可以在SuperServlet中進行，并且以Session單例的形式保存在應(yīng)用程序中。下面是Spring配置文件的例子：beans!--Beanconfiguration--beanid="businesslogicbean"class=""propertyname="proxyInterfaces"valueIBusinessLogic/value/propertypropertyname="target"reflocal="beanTarget"http://propertypropertyname="interceptorNames"listvaluethePermissionCheckBeforeAdvisor/value/list/property/bean!--BeanClasses--beanid="beanTarget"class="BusinessLogic"propertyname="user"YOURUSEROBJECT/property/bean!--Advisorpointcutdefinitionforbeforeadvice--beanid="thePermissionCheckBeforeAdvisor"class=""propertyname="advice"reflocal="thePermissionCheckBeforeAdvice"http://propertypropertyname="pattern"value.*/value/property/bean!--Adviceclasses--beanid="thePermissionCheckBeforeAdvice"class="PermissionCheckBeforeAdvice"http://beans

6結(jié)束語AOP引進了Aspect，它將影響多個類的行為封裝到一個可重用模塊中，它允許程序員對橫切關(guān)注點進行模塊化，從而消除了OOP引起的代碼混亂和分散問題，增強了系統(tǒng)的可維護性和代碼的重用性。利用AOP的攔截能力，它為我們提供了“在任何對象的方法調(diào)用前/后加入自定義行為”的能力，這使得我們可以處理企業(yè)應(yīng)用中的權(quán)限控制這一橫切關(guān)注點，并且仍然保持強類型，解耦了程