2005 年 11 月

本文的寫作源于一個(gè)真實(shí)的大型軟件開發(fā)項(xiàng)目，我們努力嘗試在這個(gè)項(xiàng)目中推廣應(yīng)用 AOP。在此我們將對(duì)曾經(jīng)面臨過的一些實(shí)際問題與困難進(jìn)行分析，試圖引發(fā)關(guān)于面向方面軟件開發(fā)(AOSD)的一些更深層次的思考。本文的作者將站在開發(fā)者 的角度做出客觀的判斷，既不是AOP的狂熱鼓吹者，同樣也不是AOP反對(duì)陣營(yíng)的一員。因此可以視作來自Java開發(fā)者對(duì)AOP技術(shù)應(yīng)用的客觀分析和建設(shè)性 意見。

關(guān)于AOP

關(guān) 于AOP的概念，筆者在這里不再贅述。誰最先創(chuàng)造了AOP，業(yè)界一直有些爭(zhēng)議，但普遍接受的說法大概是最先由Gregor J Kiczales在ECOOP'97提出來的，隨后Gregor又申請(qǐng)了AOP的專利[US06467086]。很多人可能不太服氣，因?yàn)樗麄兓蚨嗷蛏僭? 已有了類似的想法，只不過沒有想到給他起個(gè)新名字罷了。無論是OOP，MOP，還是AOP，其本質(zhì)的想法都是試圖在更貼近現(xiàn)實(shí)世界的層次上實(shí)現(xiàn)軟件開發(fā)的 模塊化。從這個(gè)角度看，AOP的想法不過是新瓶裝舊酒罷了。其實(shí)AOP作為新生事物的出現(xiàn)，并不是一種技術(shù)上的飛躍，而是軟件模塊化發(fā)展到某一個(gè)階段的一 個(gè)階段性產(chǎn)物。人的思維通常都有一些慣性，在我們飽嘗了OOP的艱辛后，有一種新的概念跳出來分析總結(jié)了OOP的某些缺點(diǎn)，而且以看起來合理的方式做出改 進(jìn)，難免會(huì)給大家一種耳目一新的感覺。但不可否認(rèn)的是，到目前為止，AOP角色所扮演的應(yīng)用角色更多的只是對(duì)OOP的一種補(bǔ)充，因此作為一種重要的 "OP"存在似乎有些名過其實(shí)，看起來更像是一種高級(jí)的設(shè)計(jì)模式。然而，在很多人的眼中AOP的分量甚至不亞于OOP，甚至AOP被視作未來軟件開發(fā)的一 個(gè)趨勢(shì)。筆者一直思考一個(gè)問題，AOP出現(xiàn)的七八年時(shí)間在IT界并不算很短了，有趣的現(xiàn)象是AOP始終保持了小火慢燉的熱度，一直沒有像大家所期望的那樣 大紅大紫起來。

那么AOP究竟在多大程度上可以幫助我們解決實(shí)際的問題呢？讓我們嘗試在一個(gè)真實(shí)的軟件開發(fā)項(xiàng)目中應(yīng)用AOP。對(duì)AOP所推 崇的各個(gè)典型應(yīng)用方向加以研究，例如，日志(Log),事務(wù)(Transaction), 安全性(Security), 線程池等等。必須說明，我們這里提到的場(chǎng)景，是有一定規(guī)模的軟件產(chǎn)品開發(fā)，我們最終完成的是百兆數(shù)量級(jí)的軟件產(chǎn)品，因此我們研究的范圍既不是程序員的個(gè)人 行為，也不是小范圍的示例。讓我們一起來看一看有什么有趣的發(fā)現(xiàn)。

回頁(yè)首

AOP的實(shí)踐

我們?cè)囼?yàn)應(yīng)用AOP的方向很多，這里僅以最具代表性的Log為例。大多數(shù)人了解AOP，都是從經(jīng)典的Log 關(guān)注點(diǎn)的剝離開始的。因此這是每一個(gè)AOP的愛好者都耳熟能詳?shù)陌咐０吹览?，?yīng)該是無可爭(zhēng)辯的。很不幸，在我們的研究過程中還是碰到了很棘手的問題。

讓我們來看一看一個(gè)經(jīng)典的AOP 做日志的例子。

我 們假定，按照AOP的思想，主邏輯的開發(fā)人員在寫代碼的時(shí)候不應(yīng)該考慮邊緣邏輯。因此，上述的日志代碼實(shí)際對(duì)主邏輯的開發(fā)者不可見。假定我們以主流的 Log4J為記日志的實(shí)現(xiàn)方式，以AspectJ作為Aspect的實(shí)現(xiàn)方式。需要重申，本文的寫作目的并不是針對(duì)某一種AOP的實(shí)現(xiàn)平臺(tái)，選用 AspectJ主要因?yàn)閺恼Z(yǔ)法的角度而言，AspectJ是目前所有AOP實(shí)現(xiàn)中覆蓋范圍最廣的一種實(shí)現(xiàn)。

這樣一個(gè)記日志的橫切關(guān)注點(diǎn)描述，是最經(jīng)典的AOP應(yīng)用，它本身是沒有任何問題的。通常我們會(huì)怎樣用它呢？在繼承了這個(gè)抽象Aspect的子Aspect實(shí)現(xiàn)中指定切入點(diǎn)的位置①，并在這個(gè)位置上將實(shí)現(xiàn)的邏輯填入通知(Advice)②。

在 一個(gè)小規(guī)模的應(yīng)用開發(fā)環(huán)境中這樣做是不會(huì)有問題的，首先，記日志的切入點(diǎn)不多，無論是采用一對(duì)一的位置直接描述，還是利用統(tǒng)一的編碼規(guī)范來約束都是可行的 方案；其次，通知中的邏輯不會(huì)很復(fù)雜。整體的軟件開發(fā)流程不會(huì)有什么變化的需要，通常的做法是由專門的Aspect開發(fā)人員統(tǒng)一編寫Aspect，而由大 家共享記Log的Aspect。但是不鼓勵(lì)每一個(gè)開發(fā)人員都寫自己的Aspect，這樣就不是橫(cross-cut)，變成過篩子了(cross- point)，軟件開發(fā)變成一盤散沙，失去控制，AOP帶來的好處喪失殆盡。

那么，在我們的項(xiàng)目中，情況怎樣呢？上述看似簡(jiǎn)單的兩個(gè)點(diǎn)都存在問題：

(1) 具我們統(tǒng)計(jì)，在我們開發(fā)的軟件上一個(gè)版本的軟件代碼中，總共有7萬句記Log的調(diào)用。如果我們不做任何相關(guān)的總結(jié)工作，直接一對(duì)一的對(duì)切入點(diǎn)進(jìn)行描述，那 么在位置①上的切入點(diǎn)描述就有7萬條之多；姑且不算工作量，即使這樣做了，將來帶來的代碼維護(hù)將是天文數(shù)字的成本，此路不通。

那么我們只能 寄希望能夠提煉出這7萬句日志調(diào)用的公共模式，我們?cè)谶@里用到的是一種優(yōu)化過的Log組件，接口與LOG4J類似，考慮到LOG4J的廣泛應(yīng)用，我們下面 將以LOG4J為參照。Log Level類中預(yù)定義了五個(gè)級(jí)別，DEBUG, INFO, WARN, ERROR，F(xiàn)ATAL，根據(jù)統(tǒng)計(jì)，F(xiàn)atal類型的調(diào)用最少，根據(jù)Fatal的級(jí)別定義，我們或許可以花一定時(shí)間整理代碼，提煉出捕捉Fatal點(diǎn)的規(guī) 則。然后次之，WARN和ERROR大約占7%左右，這一部分就不好辦了，WARN/ERROR類型的LOG并沒有嚴(yán)格的界定，代碼的分布點(diǎn)也難尋規(guī)律， 一定要找到規(guī)律，要付出相當(dāng)大的代價(jià)。最后，DEBUG, INFO占據(jù)了很大的比例30%-50%，顧名思義，這一部分的代碼出現(xiàn)的隨機(jī)性很大，無論怎樣努力都不可能找到有意義的公共規(guī)律。此路還是不通。

有 一種說法也許可以解釋這種想象：如果切入點(diǎn)難于描述的時(shí)候，很大原因是因?yàn)殛P(guān)注點(diǎn)的定義不準(zhǔn)確。此說法有一定道理，以"日志"作為一個(gè)方面來切入粒度似乎 太大了。那么，唯一的辦法是將"日志"關(guān)注點(diǎn)進(jìn)一步拆解。一直拆解到可以接受的程度。但是，我們的問題似乎還沒有解決，如果我們的項(xiàng)目足夠小，那么這樣的 拆解總是有一定的限度的，這種做法或許可行。但很不幸，我們的項(xiàng)目很大，要經(jīng)過相當(dāng)多的分解才能最終找到日志的規(guī)律性。我們還是可能需要成百上千條語(yǔ)句來 指定切入點(diǎn)的位置，最終的結(jié)果將很難維護(hù)，這樣的做法對(duì)于一個(gè)不斷演化中的項(xiàng)目而言是脆弱乃至于不可接受的。況且，像Debug這樣的Log級(jí)別，無論你 怎樣拆解，都不可能找到完美的規(guī)律。通常，任何一個(gè)系統(tǒng)中的Log都會(huì)保持邏輯的一致性，如果經(jīng)過了這樣的層層分解，Log作為一個(gè)邏輯主體的完整性被完 全破壞了。這是一種為了AOP而AOP的做法，非但工作量沒有減輕，還帶來了無窮的后患。

好了，只剩最后一招了，為了用AOP, 我們犧牲掉Log的某些特性，預(yù)先定義好編碼的規(guī)則和日志原則，強(qiáng)制推行。當(dāng)然，如果想要全面覆蓋所有的日志點(diǎn)，這樣的日志原則只能定得非常粗。從AOP 的角度來講，技術(shù)上是可行的，但粗放的日志規(guī)則會(huì)帶來Log的信息量瘋長(zhǎng)，對(duì)于我們的軟件項(xiàng)目來說，還是不可接受，因?yàn)槿罩臼チ怂木_性，會(huì)對(duì)系統(tǒng)的 維護(hù)產(chǎn)生較大影響，而且大量日志信息的增長(zhǎng)對(duì)系統(tǒng)整體運(yùn)行性能的沖擊是顯而易見的。

(2) 在圖1 的第二個(gè)要點(diǎn)上我們也同樣面臨問題，也許從圖上的例子你可能還看不出來，因?yàn)樵谒械慕榻BAOP的文檔材料中介紹Log的例子都很簡(jiǎn)單。但是現(xiàn)實(shí)生活中的 Log很不留情面。很多時(shí)候程序?qū)og的調(diào)用都有其特殊的原因，它們的Advice需要分別編寫。例如在例子產(chǎn)品中我們經(jīng)常需要把一個(gè)變量傳給"日志" 方面, 而且，經(jīng)常要傳入一個(gè)局部變量。至少現(xiàn)在，所有的AOP實(shí)現(xiàn)都還不支持對(duì)局部變量的捕捉，在可見的將來也不會(huì)有這種實(shí)現(xiàn)。好吧，只好重構(gòu)代碼，如果您想傳 參數(shù)，必須要遵守我們預(yù)先定義的編碼命名規(guī)則。但是，這樣給編程人員帶來的限制會(huì)很大，你很難說服開發(fā)人員手捧厚厚的編碼規(guī)范，小心翼翼的寫程序。

綜合上述兩個(gè)致命缺陷，我們?cè)噲D推行Log Aspect的工作已經(jīng)遇到了相當(dāng)?shù)淖枇Α?/p>

回頁(yè)首

問題分析

原本看起來一件簡(jiǎn)單的事情，現(xiàn)在變得很復(fù)雜了，最初的熱情變成了愛恨交織與困惑，一定是哪里出了問題。

在 大型的軟件開發(fā)項(xiàng)目里AOP的切入點(diǎn)應(yīng)該怎樣控制？這牽涉到開發(fā)的流程，版本控制，編碼規(guī)則等等。似乎AOP本身并沒有給出明確的答復(fù)。當(dāng)我們談OOP的 時(shí)候，涉及到的更多的是類，繼承，多態(tài)，而更深層次的方法學(xué)被隱藏在OOA與OOD中。類似的，我們?cè)谔岬紸OP的時(shí)候，表面上似乎就是Aspect， pointcut，advice，… 然而隱藏在代碼后面的面向方面的精華卻被忽略了。因此，我們主張，在我們學(xué)習(xí)應(yīng)用AOP的時(shí)候，不要過分沉迷于代碼，應(yīng)當(dāng)合理的在分析、設(shè)計(jì)上投入更多的 精力。這是我們從上述的失敗經(jīng)歷中得到的第一個(gè)教訓(xùn)。才能的。 我們不能把AOP想象成為萬靈丹，服用之后立刻生效。相反，在實(shí)際項(xiàng)目中應(yīng)用AOP需要多方面的考慮，這樣才可能對(duì)由AOP產(chǎn)生的問題胸有成竹。

從 某種意義上講，代碼級(jí)別上的面向方面, 無論是面向Java的語(yǔ)言擴(kuò)展還是XML，實(shí)現(xiàn)起來并沒有太大的不同。但是面向方面的技術(shù)也應(yīng)該體現(xiàn)在不同的抽象層面上，如果在大規(guī)模的開發(fā)中應(yīng)用， AOA(面向方面的分析)，AOD(面向方面的分析設(shè)計(jì))是必不可少的，因此，AOSD(面向方面的軟件開發(fā))更貼切的描述了面向方面實(shí)際上是一個(gè)完整的 實(shí)施過程。關(guān)于在更高層面上的AOSD，很多人正在做有益的嘗試，例如IBM 支持的基于Eclipse的CME項(xiàng)目，首先要解決的是怎樣在軟件開發(fā)的初始階段，定義合理的關(guān)注點(diǎn)，至于后面的實(shí)現(xiàn)是否基于純粹AOP的工具，并不是重 要的問題。脫離分析、設(shè)計(jì)階段的關(guān)注點(diǎn)分析，直接在代碼中使用AOP，只在小規(guī)模的應(yīng)用中可行，一旦面向大規(guī)模應(yīng)用，許多問題就會(huì)接踵而來。

除此之外，面向方面的開發(fā)過程還必須解決很多的具體問題，諸如：

• 怎 樣在切入點(diǎn)的公共模式與切入點(diǎn)的特征描述之間權(quán)衡？這是一個(gè)怎樣合理的控制AOP的粒度的問題，前面我們已經(jīng)提到過，橫切關(guān)注點(diǎn)的粒度其實(shí)是很難決定的。 在高層次上定義的橫切關(guān)注點(diǎn), 在底層實(shí)現(xiàn)的時(shí)候還可能會(huì)碰到問題。對(duì)具體的AOP實(shí)現(xiàn)，可能單純從代碼的角度來看，粒度劃分得越細(xì)越簡(jiǎn)單越好。但這樣一來，方面的代碼與核心代碼就會(huì)綁 定很死，不好維護(hù)。而且方面的代碼不優(yōu)雅，看起來好像單純把一塊代碼摘出來另放一個(gè)地方，刻意隱藏的痕跡很重，很難看出AOP的好處。但粒度如果太粗， AOP的代碼就必須依賴公共模式的總結(jié)，這樣的公共模式首先需要花功夫來定義，力求完美，因?yàn)橐?guī)則的不斷變化會(huì)帶來很多問題，所以應(yīng)盡量避免出現(xiàn)規(guī)則的頻 繁變動(dòng)。而且，規(guī)則是大家都要遵守的，這樣會(huì)帶來更多的編碼限制。當(dāng)然，對(duì)于具體的項(xiàng)目，編碼規(guī)則的多少是具體的問題，但如何能做到適度，并不是一個(gè)簡(jiǎn)單 的問題。
• 很現(xiàn)實(shí)的一個(gè)問題，如果在大型開發(fā)項(xiàng)目有多個(gè)橫切關(guān)注點(diǎn)的時(shí)候，這些關(guān)注點(diǎn)之間應(yīng)該如何打交道。在我們的實(shí)際項(xiàng)目中，就遇到這 樣一個(gè)難題，日志關(guān)注點(diǎn)在很多情況下是與其他橫切關(guān)注點(diǎn)糾纏在一起的。其中的難題是橫切關(guān)注點(diǎn)的剝離先后順序問題。在一個(gè)版本延續(xù)性的開放項(xiàng)目中，由于需 要重構(gòu)，這個(gè)問題更為突出。某些情況下，橫切關(guān)注點(diǎn)之間如果存在雙向的相互依賴，就必須要修改邏輯，屏蔽這種可能性，否則，以目前的AOP的實(shí)現(xiàn)方式，很 難處理，AOP的代碼會(huì)很難看，主邏輯的代碼重構(gòu)會(huì)紛繁瑣碎，而且極難維護(hù)。
• 在一個(gè)大型的軟件開發(fā)項(xiàng)目中，軟件的生命周期應(yīng)該都處于可 管理的狀態(tài)。如果AOP大規(guī)模介入，很多問題都變得很敏感，尤其是QA。按照AOP的想法，關(guān)注點(diǎn)是互相隔離開的，因此，實(shí)質(zhì)上AOP造成軟件模塊間的耦 合性變得松散了。軟件開發(fā)過程的松耦合必然帶來測(cè)試的復(fù)雜性。如果系統(tǒng)中的關(guān)注點(diǎn)控制在小范圍，那么這種負(fù)擔(dān)可以在小范圍的開發(fā)單位內(nèi)部消化掉，但一旦關(guān) 注點(diǎn)涉及到全局，這種變動(dòng)就會(huì)蔓延，帶來的測(cè)試和QA的額外工作會(huì)迅速增長(zhǎng)。并有可能會(huì)沖擊到現(xiàn)有的測(cè)試與QA流程。
• 大型軟件產(chǎn)品的售 后服務(wù)，通常都會(huì)在必要的時(shí)候觸及源代碼，以IBM為例，第三級(jí)的服務(wù)支持人員，將在源程序上跟蹤糾錯(cuò)。很不幸，這些人必須盡快學(xué)會(huì)AOP，否則他們將無 所適從，因?yàn)樗麄兛赡芨静恢勒麄€(gè)應(yīng)用邏輯是怎樣編織在一起的。軟件的維護(hù)與服務(wù)的成本可能會(huì)因此提高，并依賴特定的工具。

回頁(yè)首

AOSD發(fā)展方向的探討

首 先，這里我們?cè)俅螐?qiáng)調(diào)AOSD，而不是單純的AOP。面向方面的發(fā)展空間，應(yīng)該不僅僅局限于代碼層面。究竟面向方面是否會(huì)在未來很大程度上影響的軟件開發(fā) 模式，目前的形勢(shì)并不明了。面向方面的分析與設(shè)計(jì)，應(yīng)該對(duì)面向方面技術(shù)的未來起到主導(dǎo)作用。以現(xiàn)在面向代碼層的AOP的用法，坦率地講，只是一種小范圍的 設(shè)計(jì)模式，并不值得投入太大的熱情。很多熱門的松散耦合的開發(fā)模型，比如SOA，SCA等等，看起來更現(xiàn)實(shí)，更合理，他們都有類似的理念，但具有比面向方 面有更好的柔性。

面向方面的分析與設(shè)計(jì)必須能夠解決下面的問題：

首先，面向方面的方法學(xué)需要完善：

1） 怎樣從具體需求中定位橫切關(guān)注點(diǎn)；這樣的定義一定不是來自于簡(jiǎn)單的基于名字的原則，例如，Log在所有的軟件項(xiàng)目中都是橫切關(guān)注點(diǎn)嗎？如果我們軟件開發(fā)的 對(duì)象是類似IBM WebSphere 這樣的J2EE應(yīng)用服務(wù)器，那么事務(wù) (Transaction)還是橫切關(guān)注點(diǎn)嗎？

2） 怎樣合理的控制方面的粒度？從設(shè)計(jì)階段的橫切關(guān)注點(diǎn)到實(shí)現(xiàn)階段的方面，怎樣平滑的過渡？我們經(jīng)常碰到的問題是，在實(shí)現(xiàn)階段，方面之間仍然有相互依賴性的問題，怎樣才能在分析設(shè)計(jì)階段就盡量避免這些問題？

3） 關(guān)注點(diǎn)的模型表達(dá)方式，我們通過怎樣的標(biāo)準(zhǔn)形式來表達(dá)關(guān)注點(diǎn)，關(guān)注點(diǎn)之間的關(guān)系，以及橫切關(guān)注點(diǎn)與主邏輯之間的關(guān)系？

4） 這樣的橫切關(guān)注點(diǎn)分析是可以重復(fù)、可驗(yàn)證的嗎？有沒有可行的通用的方法學(xué)來幫助我們使得橫切關(guān)注點(diǎn)的識(shí)別與規(guī)范成為可控的過程？

其 次，面向方面的軟件工程是無法回避的重要問題，通過上面的問題分析，相信大家都已經(jīng)認(rèn)識(shí)到AOP對(duì)現(xiàn)有軟件過程各個(gè)階段的沖擊，因此有必要去規(guī)范適用于 AOP的新的軟件開發(fā)過程。首先，面向方面的開發(fā)必須遵循迭代的模式。但現(xiàn)有的軟件工程方法都不足以讓我們有足夠的信心在當(dāng)方面多到一定的程度時(shí)，軟件的 開發(fā)仍然是可控的。為什么面對(duì)以前的OO，基于組件的方式，甚至更新的SOA的開發(fā)，我們都不會(huì)如此的不安？主要是因?yàn)樵谶@些模式下，我們都能夠比較簡(jiǎn)單 的看到完整產(chǎn)品的雛形，而方面一旦多到某種程度，軟件的整體性就不能直觀的被感知到。因此，面向方面對(duì)開發(fā)流程的沖擊是不可避免的。特別是疊代的開發(fā)方 式，如何對(duì)每個(gè)開發(fā)循環(huán)有效控制也是很有學(xué)問的。

最后，面向方面的開發(fā)工具是大規(guī)模應(yīng)用AOP的技術(shù)保障，現(xiàn)有的開發(fā)工具都不能保證面向方面的軟件開發(fā)的效率與完整性。我們需要一種能夠更好的集成方面開發(fā)的工具。AJDT能夠提供一些幫助，但是還遠(yuǎn)遠(yuǎn)不夠。一個(gè)理想的AOP開發(fā)工具應(yīng)該支持：

1） 軟件產(chǎn)品的完整視圖，能夠以可視并且形象的方式組合橫切關(guān)注點(diǎn)和核心關(guān)注點(diǎn)

2） 能將AOP技術(shù)集成到系統(tǒng)的分析設(shè)計(jì)階段

3） 基于方面組合的測(cè)試與Debug工具，能夠靈活的根據(jù)不同的關(guān)注點(diǎn)組合進(jìn)行測(cè)試和Debug

4） 更加靈活和方便的關(guān)注點(diǎn)定義方式，對(duì)大多數(shù)Java開發(fā)者屏蔽復(fù)雜的Aspect語(yǔ)法

回頁(yè)首

總結(jié)

本 文通過我們?cè)诖笠?guī)模項(xiàng)目中應(yīng)用AOP的實(shí)際經(jīng)驗(yàn)，總結(jié)了碰到的問題和取得的進(jìn)展。通過我們的實(shí)踐與分析，我們認(rèn)為在AOP有較大發(fā)展之前，以現(xiàn)在的狀態(tài)， AOP更適合在小規(guī)模軟件開發(fā)項(xiàng)目中應(yīng)用。而AOP的更大規(guī)模應(yīng)用不僅需要代碼級(jí)AOP強(qiáng)有力的支持，更依賴于面向方面的分析設(shè)計(jì)技術(shù)與相應(yīng)軟件工程領(lǐng)域 的進(jìn)展。

最后，在看到了問題之余，我們也看到了AOP技術(shù)仍然處于一個(gè)不斷發(fā)展的階段。關(guān)于AOP的文章不斷涌現(xiàn)，AOP工具的功能在不斷 加強(qiáng)，而開發(fā)人員對(duì)AOP的接受程度也在逐步提高。樂觀的看，也許在不久的將來，AOP就能獲得理論和實(shí)踐上的長(zhǎng)足進(jìn)步，從而解決本文中提到的問題。讓我 們拭目以待。

回頁(yè)首

參考資料

1. AspectJ是目前使用最廣泛也是功能最強(qiáng)大的AOP代碼級(jí)別的實(shí)現(xiàn)。我們可以從http://www.eclipse.org/aspectj 獲得它。
2. AJDT是基于Eclipse的AspectJ的集成開發(fā)環(huán)境，它包含了最新版本的AspectJ?？梢詮?a >http://www.eclipse.org/ajdt 獲得它。
3. Http://aosd.net 上有很多AOP相關(guān)的資料和論文。另外，您也可以通過這個(gè)網(wǎng)站參加每年一次的AOSD會(huì)議。
4. Developerworks上的AOP@Work系列能夠幫助我們深入了解AOP的現(xiàn)狀
5. CME是一個(gè)有趣的工具，它對(duì)AOP在整個(gè)軟件工程生命周期中的運(yùn)用提供了支持。特別有趣的是它能夠幫助開發(fā)人員發(fā)現(xiàn)和提取Crosscutting Concern?？梢詮膆ttp://www.eclipse.org/cme獲得它。

回頁(yè)首

作者簡(jiǎn)介

	李珉 高級(jí)軟件工程師，技術(shù)經(jīng)理，IBM 中國(guó)軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 主要研究方向?yàn)镾OA，ESB，目前領(lǐng)導(dǎo)一個(gè)技術(shù)孵化項(xiàng)目小組工作在AOP與模型驅(qū)動(dòng)開發(fā)等方向。你可以通過minli@cn.ibm.com聯(lián)系他

	甘志 高級(jí)軟件工程師，IBM 中國(guó)軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 主要研究方向?yàn)锳OP、SOA和Security，他還對(duì)羽毛球運(yùn)動(dòng)很感興趣。他在上海交通大學(xué)計(jì)算機(jī)系攻讀網(wǎng)絡(luò)安全方向博士學(xué)位，期間發(fā)表了多篇論文和技術(shù)書籍。你可以通過ganzhi@cn.ibm.com聯(lián)系他。

	王強(qiáng) 軟件工程師，IBM 中國(guó)軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 從事Incubator及SOA，Grid項(xiàng)目的工作，對(duì)J2EE架構(gòu)、SOA架構(gòu)、MDA/MDD以及AOP，網(wǎng)格計(jì)算等技術(shù)有較深入的研究。

	郭迎春 軟件工程師，IBM 中國(guó)軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 有多年Java開發(fā)經(jīng)驗(yàn)，目前主要研究方向?yàn)锳OP、SOA。你可以通過guoyingc@cn.ibm.com聯(lián)系。

	劉昕鵬 軟件工程師，IBM 中國(guó)軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心 對(duì)J2EE、SOA、MDA/MDD、AOP、語(yǔ)義網(wǎng)等相關(guān)技術(shù)有濃厚興趣，并在基于Eclipse的插件開發(fā)方面有較深入的經(jīng)驗(yàn)。