殷海光，王衛(wèi)東

（江蘇科技大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，江蘇鎮(zhèn)江212003）

基于構(gòu)件的軟件復(fù)用作為一種提高軟件生產(chǎn)率和軟件質(zhì)量的有效途徑，是近幾年軟件工程界研究的重點(diǎn)之一，被認(rèn)為是繼面向?qū)ο蠓椒ㄖ蟮囊粋€(gè)新的技術(shù)熱潮[1]。另外隨著軟件系統(tǒng)的規(guī)模和復(fù)雜性的增加，軟件體系結(jié)構(gòu)的設(shè)計(jì)成為極為重要的因素，三層客戶/服務(wù)器體系結(jié)構(gòu)為企業(yè)資源規(guī)劃的整合提供了良好的框架，是建立企業(yè)級管理信息系統(tǒng)的最佳選擇。隨著體系結(jié)構(gòu)的發(fā)展，目前在多層應(yīng)用結(jié)構(gòu)方面出現(xiàn)J2EE技術(shù)和.net技術(shù)等不同的解決方案，二者各有優(yōu)缺點(diǎn)，分別適用于不同規(guī)模的系統(tǒng)的要求。J2EE平臺(tái)的核心就是EJB（EnterpriseJavaBean）構(gòu)架。EJB是開發(fā)、部署和管理可靠的企業(yè)應(yīng)用程序的一種最新框架。EJB組件作為J2EE的最重要的開發(fā)構(gòu)件技術(shù)，EJB位于J2EE業(yè)務(wù)層，主要用來實(shí)現(xiàn)企業(yè)級應(yīng)用中的業(yè)務(wù)邏輯，并且EJB技術(shù)作為J2EE中唯一的開發(fā)構(gòu)件的技術(shù)，研究EJB部署體系結(jié)構(gòu)與應(yīng)用具有重要意義[2]。

文中探討EJB的部署體系結(jié)構(gòu)的特點(diǎn)，研究采用EJB部署體系結(jié)構(gòu)的應(yīng)用系統(tǒng)的開發(fā)模型，對現(xiàn)有的EJB部署體系結(jié)構(gòu)進(jìn)行改進(jìn)，提出了一種更適應(yīng)于大型企業(yè)的分布式多層EJB部署應(yīng)用體系結(jié)構(gòu)的參考模型，提高了原有體系結(jié)構(gòu)的可擴(kuò)展性和訪問效率，使J2EE/EJB多層體系結(jié)構(gòu)更能適應(yīng)大型的企業(yè)應(yīng)用的需求。

1 EJB架構(gòu)

1.1 EJB概念

EJB（Enterprise Java Beans）是基于分布式事務(wù)處理的企業(yè)級應(yīng)用程序的組件。Sun公司發(fā)布的文檔中對EJB的定義是：EJB是用于開發(fā)和部署多層結(jié)構(gòu)的、分布式的、面向?qū)ο蟮腏ava應(yīng)用系統(tǒng)的跨平臺(tái)的構(gòu)件體系結(jié)構(gòu)。

在開發(fā)分布式系統(tǒng)時(shí)，采用EJB可以使得開發(fā)商業(yè)應(yīng)用系統(tǒng)變得容易，應(yīng)用系統(tǒng)可以在一個(gè)支持EJB的環(huán)境中開發(fā)，開發(fā)完之后部署在其它的EJB環(huán)境中，隨著需求的改變，應(yīng)用系統(tǒng)可以不加修改地遷移到其它功能更強(qiáng)、更復(fù)雜的服務(wù)器上。EJB在系統(tǒng)實(shí)現(xiàn)業(yè)務(wù)邏輯層里面負(fù)責(zé)表示程序的邏輯和提供訪問數(shù)據(jù)庫的接口。

1.2 EJB組件的體系架構(gòu)

EJB的架構(gòu)主要包括以下幾方面：

1）Enterprise Java Bean類：包含了組件的實(shí)現(xiàn)細(xì)節(jié)，是實(shí)際完成bean功能的地方。EJB容器根據(jù)需要調(diào)用這個(gè)類對bean進(jìn)行實(shí)例化。

2）EJB對象：在服務(wù)器端，一個(gè)EJB對象是一個(gè)實(shí)現(xiàn)了bean的遠(yuǎn)程接口（具有網(wǎng)絡(luò)功能）的分布式對象，它在服務(wù)器端上包裝了bean的實(shí)例。EJB對象由容器控制在適當(dāng)?shù)臅r(shí)機(jī)調(diào)用所需的服務(wù)，這些服務(wù)對客戶而言是透明的。

3）Remote接口：遵照EJB規(guī)范，所有的Remote接口都必須來源于一個(gè)通用的接口，包含了EJB對象必須實(shí)現(xiàn)的方法。

4）Home接口：開發(fā)者必須定義home接口，容器廠商則提供從home接口中產(chǎn)生home對象實(shí)現(xiàn)的方法。

1.3 EJB組件的工作流程

EJB Component在部署到應(yīng)用服務(wù)器上之后，客戶端就可以調(diào)用它來完成各種功能。工作過程如下：

1）客戶端首先通過JNDI服務(wù)檢索Home對象。在EJB應(yīng)用部署到應(yīng)用服務(wù)器上之后，容器會(huì)自動(dòng)獲得Home對象的信息并將其加入到JNDI中。

2）JNDI服務(wù)返回所查找的Home對象的引用。

3）Home對象的創(chuàng)建或者查找EJB對象。

4）Home對象將獲得的EJB對象返回給客戶端。

5）客戶端利用獲得的EJB對象引用，調(diào)用業(yè)務(wù)方法。

6）EJB對象獲得對應(yīng)bean的一個(gè)實(shí)例并將相應(yīng)的業(yè)務(wù)方法調(diào)用傳遞給該實(shí)例。

7）Bean實(shí)例通過其實(shí)現(xiàn)代碼，完成相應(yīng)的業(yè)務(wù)邏輯并將結(jié)果返回給EJB對象。

8）EJB對象將方法的結(jié)果返回給客戶端。

2 現(xiàn)有的EJB部署體系結(jié)構(gòu)

文獻(xiàn)[3]中提出了一種EJB組件的部署體系結(jié)構(gòu)，如圖1所示。在這個(gè)體系結(jié)構(gòu)中，采用EJB技術(shù)開發(fā)，將各個(gè)模塊開發(fā)成相對獨(dú)立的EJB組件，并將其部署在不同的服務(wù)器上，這樣也就是將各種任務(wù)與功能的類放到不同的服務(wù)器上，然后通過各個(gè)服務(wù)器間建立的調(diào)用規(guī)則實(shí)現(xiàn)分布式的運(yùn)算。原來在一個(gè)計(jì)算機(jī)上運(yùn)算的幾個(gè)類，分別放到其他計(jì)算機(jī)上去運(yùn)行，以便分擔(dān)運(yùn)行這幾個(gè)類所需要占用的CPU和內(nèi)存資源。同時(shí)，也可以將不同的軟件功能模塊放到不同的服務(wù)器上，當(dāng)需要修改某些功能的時(shí)候直接修改這些服務(wù)器上的類就行了，修改以后所有客戶端的軟件都被修改了。

圖1 現(xiàn)有的EJB組件的部署體系結(jié)構(gòu)

但是這種部署體系存在兩個(gè)問題，一個(gè)問題是：多個(gè)模塊服務(wù)器對應(yīng)的是同一個(gè)數(shù)據(jù)庫服務(wù)器，現(xiàn)在如果想實(shí)現(xiàn)各個(gè)服務(wù)器針對同一個(gè)數(shù)據(jù)庫的查詢，那么，不管部署多少個(gè)功能服務(wù)器，都需要針對一個(gè)數(shù)據(jù)庫服務(wù)器進(jìn)行查詢操作。也就是說，不管你的"計(jì)算"有多么"分布"也同樣需要從一臺(tái)服務(wù)器中取得數(shù)據(jù)。雖然，看起來將各個(gè)功能模塊分布在不同的服務(wù)器上從而分擔(dān)了各個(gè)主計(jì)算機(jī)的CPU資源，然而，真正的瓶頸并不在這里，而是在數(shù)據(jù)庫服務(wù)器那里。數(shù)據(jù)庫服務(wù)器都會(huì)非常忙的應(yīng)付各個(gè)服務(wù)器的查詢及操作請求。因此，通過這個(gè)結(jié)構(gòu)圖使我們了解到了EJB根本不能完全解決負(fù)載的問題，因?yàn)?，瓶頸并不在功能模塊的所在位置，而是在數(shù)據(jù)庫服務(wù)器這里。

另一個(gè)問題是：圖1這種架構(gòu)中存在兩個(gè)網(wǎng)絡(luò)，一個(gè)是"網(wǎng)絡(luò)1"，一個(gè)是"網(wǎng)絡(luò)2"，這兩個(gè)網(wǎng)絡(luò)是不同的。"網(wǎng)絡(luò)2"往往是局域網(wǎng)，一般帶寬是10M/100M，速度較快，因此到還好說，然而，"網(wǎng)絡(luò)1"往往是互聯(lián)網(wǎng)或者是利用電信網(wǎng)絡(luò)互聯(lián)VPN網(wǎng)或稱廣域網(wǎng)。"網(wǎng)絡(luò)1"的特點(diǎn)是帶寬一般較窄，如ADSL的網(wǎng)絡(luò)僅僅有512K-2M的帶寬，即使現(xiàn)在提速了，依舊達(dá)不到局域網(wǎng)的帶寬，由于廣域網(wǎng)互聯(lián)的成本較高，所以一般不會(huì)有較高的帶寬。而在這個(gè)網(wǎng)絡(luò)上恰恰傳輸?shù)氖枪δ苣K和客戶端軟件之間交換的數(shù)據(jù)，而這部分?jǐn)?shù)據(jù)恰恰優(yōu)勢非常占用帶寬的。因此，這個(gè)應(yīng)用架構(gòu)其運(yùn)行速度使非常的慢。

3 EJB部署體系結(jié)構(gòu)的改進(jìn)

圖2對以前的部署體系做了兩點(diǎn)改變，一是在應(yīng)用模塊和應(yīng)用之間添加了服務(wù)模塊的中間結(jié)構(gòu)，該服務(wù)模塊對外主要負(fù)責(zé)的是提供數(shù)據(jù)，負(fù)責(zé)應(yīng)用和具體模塊之間的數(shù)據(jù)傳遞。服務(wù)模塊內(nèi)部選擇使用哪個(gè)模塊，由選擇的模塊操作數(shù)據(jù)，然后傳遞數(shù)據(jù)到服務(wù)模塊，然后對外提供數(shù)據(jù)。經(jīng)過改進(jìn)后，應(yīng)用端只需要把需求的信息發(fā)送到服務(wù)模塊，由服務(wù)模塊選擇下級模塊，并且獲取數(shù)據(jù)，然后由服務(wù)模塊將數(shù)據(jù)傳遞到應(yīng)用端。這種方式下，主要的數(shù)據(jù)獲取以及操作都是在服務(wù)器之間進(jìn)行操作，已知的服務(wù)器之間的網(wǎng)速是很快的，能夠達(dá)到百兆級別，將耗時(shí)的工作放在服務(wù)器之間，就是“網(wǎng)絡(luò)3”。這樣就可以很好地避免因?yàn)椤熬W(wǎng)絡(luò)1”的速度慢而導(dǎo)致的整個(gè)應(yīng)用的速度的降低。

二是為每個(gè)服務(wù)配備了一個(gè)數(shù)據(jù)庫服務(wù)器。在這種情況下，每個(gè)應(yīng)用模塊都可以操作全部的數(shù)據(jù)，并且只能操作對應(yīng)的數(shù)據(jù)庫服務(wù)器，不能操作其他模塊的服務(wù)器。這樣就不會(huì)出現(xiàn)多個(gè)模塊操作同一個(gè)數(shù)據(jù)庫服務(wù)器的情況。不需要排隊(duì)等待操作統(tǒng)一數(shù)據(jù)庫的情況，也就不會(huì)花費(fèi)大量的時(shí)間用在等待的情況上。這種情況下可以有效的解決負(fù)載均衡的問題，提高了整個(gè)應(yīng)用的訪問速度。

圖2 改進(jìn)的EJB組件的部署體系結(jié)構(gòu)

圖2這種EJB構(gòu)件部署方式，不僅繼承了之前的分布式的優(yōu)點(diǎn)，而且在以前的問題上做了改變，可以彌補(bǔ)之前的問題，對于提高效率有很大的好處。在改進(jìn)后的部署體系中，當(dāng)用戶只是訪問應(yīng)用的時(shí)候，我們不需要選擇具體的下層模塊，只需要面對服務(wù)模塊即可，這樣省略了選擇時(shí)間，這樣提高了訪問效率。另外，當(dāng)用戶要操作數(shù)據(jù)的時(shí)候，我們只需要在服務(wù)模塊上選擇數(shù)據(jù)所屬的下級模塊即可，選擇完后，由下級模塊操作，并且操作的是自己的獨(dú)有的數(shù)據(jù)庫服務(wù)器，無需和別的模塊共享數(shù)據(jù)庫服務(wù)器，花費(fèi)時(shí)間排隊(duì)等待數(shù)據(jù)庫服務(wù)器的響應(yīng)，這樣提高了用戶的操作數(shù)據(jù)的效率。

4 兩種部署體系的性能測試

使用學(xué)生管理網(wǎng)站進(jìn)行測試。學(xué)生模塊設(shè)計(jì)如圖3所示。

圖3 學(xué)生管理網(wǎng)站的模塊設(shè)計(jì)圖

圖3就是學(xué)生管理網(wǎng)站的模塊設(shè)計(jì)圖，每個(gè)模塊開發(fā)一個(gè)EJB組件，對于改進(jìn)的EJB部署體系結(jié)構(gòu)，還需要開發(fā)一個(gè)服務(wù)模塊組件。然后根據(jù)兩種部署的體系結(jié)構(gòu)將組件部署到不同的服務(wù)器上。對于兩種體系做實(shí)驗(yàn)，采集數(shù)據(jù)。實(shí)驗(yàn)結(jié)果對比如下：

表1是網(wǎng)站測試結(jié)果，測試出來的是網(wǎng)站的響應(yīng)時(shí)間，連接時(shí)間，下載時(shí)間;從這些對比數(shù)據(jù)來說，采用新的部署體系，可以幫助減少響應(yīng)時(shí)間，因?yàn)椴恍枰B接具體的應(yīng)用模塊，只需要到服務(wù)端即可，提高了速度。連接時(shí)間也對比與傳統(tǒng)的模式減少了30%。但是下載時(shí)間有所增加，是因?yàn)橹虚g多了一個(gè)服務(wù)模塊，增加了轉(zhuǎn)發(fā)時(shí)間。總的耗時(shí)還是改進(jìn)方式少，所以從網(wǎng)站測試方面來說，應(yīng)該采用改進(jìn)的模式。

表1 網(wǎng)站測速比較

表2 網(wǎng)站數(shù)據(jù)操作比較

表2是負(fù)載測試結(jié)果，主要的是采用對兩種部署體系，由用戶向數(shù)據(jù)庫做1 000次的查詢，查詢中包括所有的模塊，測試其中的消耗時(shí)間，以及正確率。從結(jié)果來看，消耗時(shí)間減少了12.5%，正確率提高了2%。這是因?yàn)樵谛碌母倪M(jìn)部署模式中，每個(gè)模塊對應(yīng)一個(gè)數(shù)據(jù)庫服務(wù)器，不需要排隊(duì)等候查詢，只需要操作自己對應(yīng)的數(shù)據(jù)庫即可，提高了效率，而且不會(huì)出現(xiàn)與其他模塊數(shù)據(jù)交叉的問題。

由兩次測試結(jié)果得知，還是改進(jìn)模式的性能更好一點(diǎn)。

5 結(jié)束語

通過實(shí)驗(yàn)，EJB部署體系的改進(jìn)確實(shí)能夠提高網(wǎng)站的性能，能夠解決數(shù)據(jù)庫負(fù)載的問題，以及網(wǎng)絡(luò)傳遞數(shù)據(jù)慢的問題，對于提高應(yīng)用開發(fā)有很大的好處。但是同樣存在一些小問題，還需要改進(jìn)，就是改進(jìn)后對于服務(wù)器的硬件資源需求增大了，對于一些小型的項(xiàng)目來說，成本太大，需要綜合考慮。

[1]張友生.軟件體系結(jié)構(gòu)[M].北京：清華大學(xué)出版社，2004.

[2]梅宏，申峻嶸.軟件體系結(jié)構(gòu)研究進(jìn)展[J].軟件學(xué)報(bào)，2006（6）：1257-1275.

[3]陳立巖.EJB組件技術(shù)及應(yīng)用[J].計(jì)算機(jī)技術(shù)與發(fā)展，2007（3）：62-64.

[4]劉恒.EJB性能改進(jìn)研究與實(shí)踐[J].微計(jì)算機(jī)信息，2006（09X）：313-314.

[5]梅宏，陳鋒，馮耀東.ABC：基于體系結(jié)構(gòu)、面向構(gòu)件的軟件開發(fā)方法[J].軟件學(xué)報(bào)，2003（4）：721-732.

[6]黃全舟，梁廣吉.EJB體系結(jié)構(gòu)及其應(yīng)用研究[J].計(jì)算機(jī)技術(shù)與發(fā)展，2006（11）：148-150.

[7]鐘元生，徐娟，陳媚.網(wǎng)站功能與性能測試方法初探[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2007（11）：109-113.

[8]鄧雄，常創(chuàng)業(yè)，吳際，等.模型驅(qū)動(dòng)的EJB構(gòu)件測試建模研究[J].電子學(xué)報(bào)，2006（S1）：2467-2472.

[9]陶傳奇，李必信，Jerry Gao等.基于模型的構(gòu)件軟件修改影響分析[J].軟件學(xué)報(bào)，2013（5）：942-960.

[10]孫小兵，李斌，陳穎.軟件修改影響分析研究與進(jìn)展[J].電子學(xué)報(bào)，2014（12）：2467-2476.

[11]鐘冠群，李佳倫，杜輝.基于構(gòu)件的軟件工程中構(gòu)件模型的分析[J].科技信息，2010（3）：44-45.

[12]趙會(huì)群，孫晶，魏瑩，等.基于模型的網(wǎng)構(gòu)軟件可達(dá)性檢測方法研究[J].計(jì)算機(jī)學(xué)報(bào)，2011（6）：1001-1011.

[13]Hubert Garavel，F(xiàn)rédéric Lang，RaduMateescu.An overview of CADP 2001[C]//Proceedings of the European Associa-tion for Software Science and Technology（EASST）Newslet-ter，2002（4）：13-24.

[14]Hassan A E，Holt R C.Architecture Recovery of Web Applications[C]//In Proceedings of 24th International Conference on Software Engineering，2002：19-25.

[15]Schlingloff Holger，Martens Axel，Schmidt Karsten.Modelingand modelcheckingWeb services[J].ElectronicNotesinTheoreticalComputer Science，2005，126（8）：3-26.