EJB部署體系改進

殷海光，王衛東

（江蘇科技大學計算機科學與工程學院，江蘇鎮江212003）

基于構件的軟件復用作為一種提高軟件生產率和軟件質量的有效途徑，是近幾年軟件工程界研究的重點之一，被認為是繼面向對象方法之后的一個新的技術熱潮[1]。另外隨著軟件系統的規模和復雜性的增加，軟件體系結構的設計成為極為重要的因素，三層客戶/服務器體系結構為企業資源規劃的整合提供了良好的框架，是建立企業級管理信息系統的最佳選擇。隨著體系結構的發展，目前在多層應用結構方面出現J2EE技術和.net技術等不同的解決方案，二者各有優缺點，分別適用于不同規模的系統的要求。J2EE平臺的核心就是EJB（EnterpriseJavaBean）構架。EJB是開發、部署和管理可靠的企業應用程序的一種最新框架。EJB組件作為J2EE的最重要的開發構件技術，EJB位于J2EE業務層，主要用來實現企業級應用中的業務邏輯，并且EJB技術作為J2EE中唯一的開發構件的技術，研究EJB部署體系結構與應用具有重要意義[2]。

文中探討EJB的部署體系結構的特點，研究采用EJB部署體系結構的應用系統的開發模型，對現有的EJB部署體系結構進行改進，提出了一種更適應于大型企業的分布式多層EJB部署應用體系結構的參考模型，提高了原有體系結構的可擴展性和訪問效率，使J2EE/EJB多層體系結構更能適應大型的企業應用的需求。

1 EJB架構

1.1 EJB概念

EJB（Enterprise Java Beans）是基于分布式事務處理的企業級應用程序的組件。Sun公司發布的文檔中對EJB的定義是：EJB是用于開發和部署多層結構的、分布式的、面向對象的Java應用系統的跨平臺的構件體系結構。

在開發分布式系統時，采用EJB可以使得開發商業應用系統變得容易，應用系統可以在一個支持EJB的環境中開發，開發完之后部署在其它的EJB環境中，隨著需求的改變，應用系統可以不加修改地遷移到其它功能更強、更復雜的服務器上。EJB在系統實現業務邏輯層里面負責表示程序的邏輯和提供訪問數據庫的接口。

1.2 EJB組件的體系架構

EJB的架構主要包括以下幾方面：

1）Enterprise Java Bean類：包含了組件的實現細節，是實際完成bean功能的地方。EJB容器根據需要調用這個類對bean進行實例化。

2）EJB對象：在服務器端，一個EJB對象是一個實現了bean的遠程接口（具有網絡功能）的分布式對象，它在服務器端上包裝了bean的實例。EJB對象由容器控制在適當的時機調用所需的服務，這些服務對客戶而言是透明的。

3）Remote接口：遵照EJB規范，所有的Remote接口都必須來源于一個通用的接口，包含了EJB對象必須實現的方法。

4）Home接口：開發者必須定義home接口，容器廠商則提供從home接口中產生home對象實現的方法。

1.3 EJB組件的工作流程

EJB Component在部署到應用服務器上之后，客戶端就可以調用它來完成各種功能。工作過程如下：

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

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

3）Home對象的創建或者查找EJB對象。

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

5）客戶端利用獲得的EJB對象引用，調用業務方法。

6）EJB對象獲得對應bean的一個實例并將相應的業務方法調用傳遞給該實例。

7）Bean實例通過其實現代碼，完成相應的業務邏輯并將結果返回給EJB對象。

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

2 現有的EJB部署體系結構

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

圖1 現有的EJB組件的部署體系結構

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

另一個問題是：圖1這種架構中存在兩個網絡，一個是"網絡1"，一個是"網絡2"，這兩個網絡是不同的。"網絡2"往往是局域網，一般帶寬是10M/100M，速度較快，因此到還好說，然而，"網絡1"往往是互聯網或者是利用電信網絡互聯VPN網或稱廣域網。"網絡1"的特點是帶寬一般較窄，如ADSL的網絡僅僅有512K-2M的帶寬，即使現在提速了，依舊達不到局域網的帶寬，由于廣域網互聯的成本較高，所以一般不會有較高的帶寬。而在這個網絡上恰恰傳輸的是功能模塊和客戶端軟件之間交換的數據，而這部分數據恰恰優勢非常占用帶寬的。因此，這個應用架構其運行速度使非常的慢。

3 EJB部署體系結構的改進

圖2對以前的部署體系做了兩點改變，一是在應用模塊和應用之間添加了服務模塊的中間結構，該服務模塊對外主要負責的是提供數據，負責應用和具體模塊之間的數據傳遞。服務模塊內部選擇使用哪個模塊，由選擇的模塊操作數據，然后傳遞數據到服務模塊，然后對外提供數據。經過改進后，應用端只需要把需求的信息發送到服務模塊，由服務模塊選擇下級模塊，并且獲取數據，然后由服務模塊將數據傳遞到應用端。這種方式下，主要的數據獲取以及操作都是在服務器之間進行操作，已知的服務器之間的網速是很快的，能夠達到百兆級別，將耗時的工作放在服務器之間，就是“網絡3”。這樣就可以很好地避免因為“網絡1”的速度慢而導致的整個應用的速度的降低。

二是為每個服務配備了一個數據庫服務器。在這種情況下，每個應用模塊都可以操作全部的數據，并且只能操作對應的數據庫服務器，不能操作其他模塊的服務器。這樣就不會出現多個模塊操作同一個數據庫服務器的情況。不需要排隊等待操作統一數據庫的情況，也就不會花費大量的時間用在等待的情況上。這種情況下可以有效的解決負載均衡的問題，提高了整個應用的訪問速度。

圖2 改進的EJB組件的部署體系結構

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

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

使用學生管理網站進行測試。學生模塊設計如圖3所示。

圖3 學生管理網站的模塊設計圖

圖3就是學生管理網站的模塊設計圖，每個模塊開發一個EJB組件，對于改進的EJB部署體系結構，還需要開發一個服務模塊組件。然后根據兩種部署的體系結構將組件部署到不同的服務器上。對于兩種體系做實驗，采集數據。實驗結果對比如下：

表1是網站測試結果，測試出來的是網站的響應時間，連接時間，下載時間;從這些對比數據來說，采用新的部署體系，可以幫助減少響應時間，因為不需要連接具體的應用模塊，只需要到服務端即可，提高了速度。連接時間也對比與傳統的模式減少了30%。但是下載時間有所增加，是因為中間多了一個服務模塊，增加了轉發時間。總的耗時還是改進方式少，所以從網站測試方面來說，應該采用改進的模式。

表1 網站測速比較

表2 網站數據操作比較

表2是負載測試結果，主要的是采用對兩種部署體系，由用戶向數據庫做1 000次的查詢，查詢中包括所有的模塊，測試其中的消耗時間，以及正確率。從結果來看，消耗時間減少了12.5%，正確率提高了2%。這是因為在新的改進部署模式中，每個模塊對應一個數據庫服務器，不需要排隊等候查詢，只需要操作自己對應的數據庫即可，提高了效率，而且不會出現與其他模塊數據交叉的問題。

由兩次測試結果得知，還是改進模式的性能更好一點。

5 結束語

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

[1]張友生.軟件體系結構[M].北京：清華大學出版社，2004.

[2]梅宏，申峻嶸.軟件體系結構研究進展[J].軟件學報，2006（6）：1257-1275.

[3]陳立巖.EJB組件技術及應用[J].計算機技術與發展，2007（3）：62-64.

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

[5]梅宏，陳鋒，馮耀東.ABC：基于體系結構、面向構件的軟件開發方法[J].軟件學報，2003（4）：721-732.

[6]黃全舟，梁廣吉.EJB體系結構及其應用研究[J].計算機技術與發展，2006（11）：148-150.

[7]鐘元生，徐娟，陳媚.網站功能與性能測試方法初探[J].計算機系統應用，2007（11）：109-113.

[8]鄧雄，常創業，吳際，等.模型驅動的EJB構件測試建模研究[J].電子學報，2006（S1）：2467-2472.

[9]陶傳奇，李必信，Jerry Gao等.基于模型的構件軟件修改影響分析[J].軟件學報，2013（5）：942-960.

[10]孫小兵，李斌，陳穎.軟件修改影響分析研究與進展[J].電子學報，2014（12）：2467-2476.

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

[12]趙會群，孫晶，魏瑩，等.基于模型的網構軟件可達性檢測方法研究[J].計算機學報，2011（6）：1001-1011.

[13]Hubert Garavel，Fré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.