Spring中AOP的連接點檢測器

摘要：越來越多的系統(tǒng)開始使用AOP（面向切面編程），面向切面編程越來越重要，但是AOP的連接點丟失問題一直未能很好的解決，該文針對使用Spring框架的系統(tǒng)中日志生成業(yè)務設計了一種連接點檢測器，可以遍歷所有連接點，并在數(shù)據(jù)庫中維護連接點狀態(tài)。

關鍵詞：Spring；AOP；連接點；面向切面編程；連接點丟失

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2013）09-2151-03

Spring中可以設定一種規(guī)范的方法名前綴來使該方法變成切入點實現(xiàn)切面業(yè)務，例如日志，安全驗證等。當一個方法運行時spring就會檢測該方法是否符合切入點特征，但是這種方法會出現(xiàn)很多人為的失誤或者錯誤，假如我們不經(jīng)意的弄錯了方法名或者某方法的名稱與該前綴相同，這個方法將不會被執(zhí)行切面的業(yè)務或者多余的執(zhí)行了切面業(yè)務，所以我們設計了一種檢測器，將所有的連接點存入表中進行維護，來解決人為造成的連接點丟失或錯配問題。

1 AOP簡介及Spring中基于AOP技術對日志的管理原理

1.1 AOP簡介

它利用一種稱為“橫切”的技術，剖解開封裝的對象內(nèi)部，并將那些影響了多個類的公共行為封裝到一個可重用模塊，并將其名為“Aspect” ，便于減少系統(tǒng)的重復代碼，降低模塊間的耦合度，并有利于未來的可操作性和可維護性[1]。AOP代表的是一個橫向的關系，如果說“對象”是一個空心的圓柱體，其中封裝的是對象的屬性和行為；那么面向方面編程的方法，就仿佛一把利刃，將這些空心圓柱體剖開，以獲得其內(nèi)部的消息。而剖開的切面，也就是所謂的“方面”了。然后它又以巧奪天功的妙手將這些剖開的切面復原，不留痕跡。

圖1 AOP動態(tài)代理實現(xiàn)原理示意圖

上圖為用動態(tài)代理的方式實現(xiàn)AOP的示意圖，調(diào)用者捕捉到我們的連接點，如圖中的原始對象，然后用代理封裝對象，代理中加入我們要對關注點實施的操作，如記錄，參數(shù)驗證等。然后將結果返回給調(diào)用者，這就簡單的實現(xiàn)了一個AOP完整實現(xiàn)過程。

1.2 AOP里的重要概念

1）join point（連接點）：是程序執(zhí)行中的一個精確執(zhí)行點，例如類中的一個方法。它是一個抽象的概念，在實現(xiàn)AOP時，并不需要去定義一個join point[2]。

2）point cut（切入點）：本質(zhì)上是一個捕獲連接點的結構。在AOP中，可以定義一個point cut[3]，來捕獲相關方法的調(diào)用。

3）advice（通知）：是point cut的執(zhí)行代碼，是執(zhí)行“方面”的具體邏輯[4]。

4）aspect（方面）：point cut和advice結合起來就是aspect，它類似于OOP中定義的一個類，但它代表的更多是對象間橫向的關系[5]。

5）introduce（引入）：為對象引入附加的方法或?qū)傩裕瑥亩_到修改對象結構的目的。有的AOP工具又將其稱為mixin[6]。

上述的技術特性組成了基本的AOP技術，大多數(shù)AOP工具均實現(xiàn)了這些技術。它們也可以是研究AOP技術的基本術語。

2.3 AOP技術的缺點分析

AOP技術產(chǎn)生的結構沖突問題，我們可以利用反射機制來解決[7]。采用AOP技術將橫切代碼與基礎代碼分離，這樣雖然減少了代碼的冗余且方便代碼的管理，但是會產(chǎn)生一個結構沖突的問題，如果程序被多次修改，aspect面的程序和連接點的連接可能被影響到。所以就出現(xiàn)了反射機制，如果利用反射機制，在AOP切面代碼編織進入連接點時，在這切面與連接點中間形成一個定義層，通過這個定義層來解決程序被修改而導致的結構問題[8]。

AOP技術產(chǎn)生的連接點丟失和錯誤配置問題，我自己開發(fā)設計了一種連接點統(tǒng)一管理的機制來解決這個問題。在基于AOP的系統(tǒng)設計中，連接點的定義一般會以一種規(guī)則形式[9]，如果連接點因為某些人為原因或者程序的修改，導致某些連接點丟失，或者錯誤匹配到了不同的aspect切面上，就導致了連接點丟失錯配問題[10]。如果我們把所有的連接點進行統(tǒng)一的存儲管理，每次系統(tǒng)程序修改后，我們利用這個連接點管理機制對連接點進行統(tǒng)一檢測，然后發(fā)現(xiàn)其中的問題，我們就可以發(fā)現(xiàn)并解決出現(xiàn)錯誤的問題，把有問題或者有可能出現(xiàn)問題的連接點導出一個連接點報告，這樣我們就可以直觀有效的發(fā)現(xiàn)出現(xiàn)的問題，從而解決連接點丟失和連接點錯配的問題。

2.4 連接點管理機制的提出

在一個基于AOP的系統(tǒng)中，會有非常多的連接點，這些連接點都是我們進行定義的，但是在定義的時候，可能會出現(xiàn)一些人為的失誤或者程序修改造成的連接點出現(xiàn)問題，所以我們提出了連接點管理機制。

連接點的管理機制主要思想就是把程序中所有定義過的連接點進行統(tǒng)計存儲，當我們程序修改后，啟動這個連接點管理機制，我們就可以通過我們存儲的信息，與程序修改后更新的連接點信息進行比較，得出有問題的連接點。

比如在Spring框架中，可以設定一種規(guī)范的方法名前綴來使該方法變成切入點實現(xiàn)切面業(yè)務[11]，我們針對這個原理，通過一種方式，將一個包內(nèi)所有的類中，所有符合的方法進行收集整理，存入數(shù)據(jù)庫中，對他們的狀態(tài)進行維護，每次檢測都會得出連接點的丟失與改動的詳細記錄。通過這種方式來推斷連接點的安全與否。

3 基于AOP的連接點檢測器的實現(xiàn)

3.1 基于AOP的連接點檢測器的原理

在Spring框架中，可以設定一種規(guī)范的方法名前綴來使該方法變成切入點實現(xiàn)切面業(yè)務，我們針對這個原理，通過一種方式，將一個包內(nèi)所有的類中，所有符合的方法進行收集整理，存入數(shù)據(jù)庫中，對他們的狀態(tài)進行維護，每次檢測都會得出連接點的丟失與改動的詳細記錄。通過這種方式來推斷連接點的安全與否。

3.2 數(shù)據(jù)庫的設計

在整個檢測器的設計中，數(shù)據(jù)庫是非常重要的一個環(huán)節(jié)，我們要將所有的方法存入到數(shù)據(jù)庫中進行維護，通過數(shù)據(jù)庫的方式，可以直觀快速的找到問題的所在。

數(shù)據(jù)庫的重要字段：UID，methodName，methodClass，methodPackage，state。UID是方法的唯一標識，methodName，methodClass，methodPackage表示出方法的名字，來自于哪個類，哪個包，可以唯一確定一個方法。State是方法的狀態(tài)，表示出這個方法是否為丟失連接點或者是新加入的連接點。

3.3 具體的實現(xiàn)方法

檢測器的輸入為包名和在Spring中設置的方法名的正則式，如*add。輸出為變動的方法名及變動原因。

1）首先在Spring的日志程序段中加入對所捕捉到的切入點方法名的檢測程序，如果此方法沒有在數(shù)據(jù)庫中，則將此方法存入數(shù)據(jù)庫，如果已經(jīng)存在數(shù)據(jù)庫中的話，則不進行任何操作。

2）輸入包名及正則式，遍歷整個包，將所有的類找出存入LIST。輸入以包名為單位，遍歷整個包中的所有類，存入一個LIST。

3）遍歷所有類中，符合正則式的方法存入CLASSLIST。通過LIST，挨個將類取出進行遍歷，通過Field[] fields =a.class.getFields（）； Method[] methods=a.getMethods（）；這兩個方法把類中的所有方法存入一個LIST中，然后通過輸入的正則式篩選出符合條件的方法，將他們存入的MethodList中。

4）查詢表中數(shù)據(jù)，如果是第一次運行則將MethodList所有方法插入表中，如果不是第一次運行則與MethodList對照。

3.4連接點管理機制算法

步驟 1遍歷所有連接點.得到LIST1

步驟 2查詢joinpoint表得到 連接點LIST2

步驟 3比較LIST1 LIST2的長度

步驟 4如果LENGTH 1 = LENGTH 2 那么比較LIST1 和 LIST2中的連接點是否一致

步驟 5如果LENGTH 1 ！= LENGTH 2 且 LENGTH1 < LENGTH2那么查找丟失的連接點

步驟 6如果LENGTH1 ！= LENGTH 2 且 LENGTH1>LENGTH2 查找LIST1中多出的連接點

步驟 7導出結果，得到連接點的改動。

4 結束語

本文的設計的檢測器，針對Spring框架，利用此檢測器可以有效的避免連接點丟失，連接點錯配的問題，因為有數(shù)據(jù)庫對所有符合的方法進行維護管理，可以直觀而且快速的檢測到問題的所在。但是由于使用到了數(shù)據(jù)庫，而且要遍歷整個工程包，所以工作量會比較大，如果工程太大的話，檢測的效率會是個問題。

參考文獻：

[1] Hameed K， Williams R，Smith J.Aspect Oriented Software Fault Tolerance[C].Proceedings of 4th Interna-tional Conference on Computer Science & Education （WCE09）， London， 2009（1）：1-3.

[2] Breivold H P，Crnkovic I.A systematic review of software archi-tecture evolution research[C]. Information and Software Technology，2012：16-40.

[3] Banani R，Graham N.Methods for evaluating software architec-ture：a survey[R]. Technical Report 2008-545 Queens University，2008 ： 1-82.

[4] YE Peng，NI You-cong，HU Ming.Research on measurement tech-nique for evaluating adaptability of aspect-oriented software architec-ture[M]. Advanced Materials Research，2011， 268-270： 1307-1312.

[5] Garcia-magarino I，Cossentino M，Seidita V.A metricssuite for evaluating agent-oriented architectures[C]. Proc of the 25thACM Symposium on Applied Computing ， 2010： 912-919.

[6] SANTANNA C，GAMEZ N，GARCIA A，et al.General architectureevaluation process/metrics，AOSD-Europe Deliverable D85[Z].2007.

[7] Jones M，Hamlen K W.Disambiguating Aspect-Oriented Security Poli-cies[C]. Proceedingsof of the 9th International Confidence on Aspect-Oriented Software Development（AOSD10） . 2010 .

[8] Clement A，Colyer A，Harley G，et al.Using eclipse aspect：your first steps[EB/OL]. http：//www.informit.com/articles/article.aspx？p=357692.

[9] Liliana Dobrica，Eila Niemela.A survey on software architecture analysis methods[M]. IEEE Transactions on Software Engineering，2002 .

[10] Joseph D. Gradecki，Nicholas Lesiecki.Mastering Aspect： Aspect-Oriented Programming in Java[Z]. 2005

[11] SantAnna C，Lobato C，Kulesza U，et al. On the quantitative assessment of modular multi-agent system architectures [C].Proc of International Conference on Multiagent Systems and Software Architecture. London： Springer-Verlag，2006： 111-135.