信息管理系統(tǒng)中實體bean問題之解決方案研究

閆寶華

甘肅民族師范學(xué)院 甘肅 747000

0 引言

J2EE(Java 2 Platform，Enterprise Edition)是SUN公司定義的一個開發(fā)分布式企業(yè)級應(yīng)用的規(guī)范。它提供了一個多層次的分布式應(yīng)用模型和一系列開發(fā)技術(shù)規(guī)范。J2EE技術(shù)之所以贏得廣泛重視的原因之一就是EJB(Enterprise JavaBean)。它們提供了一個框架來開發(fā)和實施分布式商務(wù)邏輯，每個EJB是按功能邏輯劃分的，開發(fā)時不必關(guān)注系統(tǒng)底層細(xì)節(jié)問題，只關(guān)注具體的事務(wù)分析。EJB有三種類型：會話Bean(SessionBean)、實體 Bean(Entity Bean)和消息驅(qū)動Bean(MessageDriven Bean)。實體Bean代表數(shù)據(jù)庫或另外一個企業(yè)應(yīng)用系統(tǒng)中的數(shù)據(jù)對象。如代表數(shù)據(jù)庫的一行記錄。實體 Bean不包括商務(wù)邏輯，它們只是數(shù)據(jù)模型。因此，在EJB中設(shè)計一個實體bean時，需要考慮的重要選擇之一：是設(shè)計一個粗粒度(coarse-grained)的實體 bean，還是一個細(xì)粒度(fine-grained)的實體bean。粗粒度一般表示類別級(the type of object)，即僅考慮對象的類別，不考慮對象的某個特定實例。比如，用戶管理中，創(chuàng)建、刪除，對所有的用戶都一視同仁，并不區(qū)分操作的具體對象實例。細(xì)粒度表示實例級，即需要考慮具體對象的實例(the instance of object)，當(dāng)然，細(xì)粒度是在考慮粗粒度的對象類別之后才再考慮特定實例。通常，決定到底該采用粗粒度還是細(xì)粒度是很難的。這最好通過統(tǒng)一建模語言(Unified Modeling Language, UML)模型中的模型化關(guān)系來決定。

1 信息化管理系統(tǒng)(MIS)整體架構(gòu)設(shè)計

目前，大多數(shù)院校開發(fā)的信息化管理系統(tǒng)在整體上采用B/S(Brower/Server)和 C/S(Client/Server)混合結(jié)構(gòu)。其中B(Brower/Server)端，即 Web應(yīng)用部分一般采用基于J2EE(Java 2 Platform Enterprise Edition)的三層架構(gòu)，即將表現(xiàn)層，中間層和數(shù)據(jù)層分開，將所有的商業(yè)邏輯和工作流放入服務(wù)器端。在中間應(yīng)用層中，采用以 EJB(Enterprise JavaBeans)為中心、Servlets做控制、JSP(Java Server Pages)負(fù)責(zé)呈現(xiàn)邏輯的 MVC(Model-View-Control)結(jié)構(gòu)，即模型－視圖－控制器結(jié)構(gòu)(如圖1所示)。MVC結(jié)構(gòu)把功能模塊、顯示模塊和控制模塊分離，使各部分之間協(xié)調(diào)工作、耦合性較小。EJB負(fù)責(zé)業(yè)務(wù)邏輯部分。為了使系統(tǒng)開發(fā)與維護(hù)更具有可操作性，使系統(tǒng)的體系結(jié)構(gòu)更清晰，軟件開發(fā)中將業(yè)務(wù)邏輯劃分為應(yīng)用邏輯和商業(yè)邏輯兩個部分，其中應(yīng)用邏輯部分負(fù)責(zé)用戶的請求，商業(yè)邏輯部分負(fù)責(zé)與數(shù)據(jù)庫服務(wù)器的操作。應(yīng)用邏輯以應(yīng)用的需求條件調(diào)用商業(yè)邏輯，商業(yè)邏輯將相應(yīng)結(jié)果再返回給應(yīng)用邏輯。業(yè)務(wù)邏輯功能的劃分使EJB的處理更加自如，縮短開發(fā)周期，提高開發(fā)質(zhì)量。同時也提高了系統(tǒng)的可復(fù)用性。

圖1 MIS系統(tǒng)整體架構(gòu)設(shè)計(BS和CS混合結(jié)構(gòu))

2 MIS系統(tǒng)中數(shù)據(jù)模型的分析

2.1 模型分析

設(shè)計 EJB層，首先必須了解它的數(shù)據(jù)模型。如某學(xué)院MIS系統(tǒng)B端共有用戶登錄、課程查詢、培養(yǎng)方案查詢、學(xué)生信息管理、教師信息管理、學(xué)生選課管理等6個功能模塊。其中學(xué)生信息模塊——學(xué)生信息繁多，關(guān)系復(fù)雜。該學(xué)院學(xué)生有三類：本科自招生US(Undergraduate Student)、本科轉(zhuǎn)專業(yè)學(xué)生CSUS(Change Specialty Undergraduate Student)、碩士研究生GS(Graduate Student)，每類學(xué)生包含六大類信息：基本信息(Basic Information)、獎罰信息(Rewards Punishment Record)、學(xué)籍變動信息(Status Change Record)、課程成績信息(Course)、班級(Class)、研究方向和專業(yè)(Study Direction and Specialty)。每大類信息包括各種類型學(xué)生對應(yīng)的詳細(xì)分類信息。各實體、視圖之間的整體關(guān)系如圖2所示。

圖2 某MIS系統(tǒng)學(xué)生信息管理模塊實體關(guān)系圖

2.2 細(xì)粒度實體bean問題

在EJB應(yīng)用時的一個常用經(jīng)驗是把對象模型直接映射到實體bean，也就是說，對象模型中的每個類被直接轉(zhuǎn)換成一個實體 bean。隨著企業(yè) bean數(shù)目的增加，容器和網(wǎng)絡(luò)負(fù)載也會同步增加。這類映射也把表間關(guān)系(又稱主關(guān)鍵字/外部關(guān)鍵字)實現(xiàn)為實體bean到實體bean的關(guān)系。這將會對應(yīng)用的性能產(chǎn)生負(fù)面的影響。

對象模型直接映射到實體 bean的設(shè)計方法對于實體關(guān)系比較簡單的模塊(如前述系統(tǒng) B端中的用戶登錄模塊、教師信息模塊、培養(yǎng)方案查詢、課程查詢等)的設(shè)計實現(xiàn)是最佳的。因此這些模塊開發(fā)時使用了容器管理持久化 CMP(Container Managed Persistence)實體bean技術(shù)對所用到的表進(jìn)行了映射，原因是這些數(shù)據(jù)結(jié)構(gòu)相對簡單，數(shù)據(jù)單純，不需要進(jìn)行非常復(fù)雜、多樣的查詢，系統(tǒng)對數(shù)據(jù)表的操作不頻繁，通常情況下對性能不敏感，故采用了CMP實體bean技術(shù)。CMP中只提供最基本的查詢方法，所有的程序邏輯都封裝在對應(yīng)的會話Bean中，會話Bean和CMP一同部署，故可以采用本地接口訪問實體Bean，提高效率。客戶端僅僅與會話Bean進(jìn)行交互(會話外觀設(shè)計模式)。該設(shè)計的好處是隱藏了數(shù)據(jù)邏輯，MVC的結(jié)構(gòu)非常清楚，后期的數(shù)據(jù)維護(hù)也比較簡單。

但是對于像學(xué)生信息管理模塊和學(xué)生選課管理這樣實體關(guān)系復(fù)雜，對象數(shù)目眾多的模塊來說，將導(dǎo)致大量的細(xì)粒度實體 bean。將嚴(yán)重影響應(yīng)用的可擴(kuò)展性，故使用 bean管理的持久性BMP(Bean Managed Persistence)實體bean技術(shù)，但需要開發(fā)人員編寫持久性代碼而容器只是確定何時執(zhí)行該代碼。

在學(xué)生信息模塊中，三種基本信息表(GSBaInf, USBaInf,CSUSBaInf)與其對應(yīng)的家庭成員社會關(guān)系(GSFamSoRel,USFamSoRel, CSUSFamSoRel)、學(xué)習(xí)工作經(jīng)歷(GSLeWoExp,USLeWoExp, CSUSLeWoExp)、獎懲記錄(GSRePuRec,USRePuRec, CSUSRePu-Rec)、學(xué)籍變動記錄(GSStaChgRec,USStaChgRec, CSUSStaChgRec)、班級(Cla)、研究方向(StudDir)之間的表關(guān)系如果直接映射到實體bean時，會產(chǎn)生很多問題，也就是說細(xì)粒度實體bean會影響許多領(lǐng)域：一是影響實體關(guān)系，把對象模型直接映射到實體bean，會將對象間的關(guān)系轉(zhuǎn)換為實體bean之間的關(guān)系。結(jié)果是一個實體bean往往包含或持有對其他實體bean的遠(yuǎn)程應(yīng)用。這樣在增加代碼的復(fù)雜性之外，它還會降低系統(tǒng)的靈活性；二是影響可管理性，細(xì)粒度實體bean會導(dǎo)致系統(tǒng)中存在大量的實體bean。容器會創(chuàng)建大量對象來支持每個實體bean實例。大量的實體bean會產(chǎn)生更多需要維護(hù)的代碼和類。這樣會對應(yīng)用程序的性能產(chǎn)生負(fù)面影響；三是影響網(wǎng)絡(luò)性能，細(xì)粒度實體 bean潛在地有更多的實體bean之間的關(guān)系，關(guān)系數(shù)的增加肯定會導(dǎo)致遠(yuǎn)程調(diào)用的增加，結(jié)果是由于網(wǎng)絡(luò)負(fù)載而降低系統(tǒng)的可擴(kuò)展性；四是影響數(shù)據(jù)庫模式依賴，當(dāng)實體bean是細(xì)粒度時，每個實體bean實例通常都被看作數(shù)據(jù)庫中的一行，客戶端使用這些細(xì)粒度實體bean時，它們實際上操作在數(shù)據(jù)庫中的行層次，則客戶端就變得對數(shù)據(jù)庫模式很依賴。

3 在MIS系統(tǒng)中的解決方案

3.1 把實體 bean設(shè)計并實現(xiàn)成具有根和依賴對象的粗粒度對象——復(fù)合實體

3.1.1 復(fù)合實體及其相關(guān)概念

如果把學(xué)生信息模塊的對象模型直接映射到實體bean，將導(dǎo)致大量的細(xì)粒度實體bean。從而帶來網(wǎng)絡(luò)負(fù)載、數(shù)據(jù)庫模式依賴及管理復(fù)雜等問題。為解決細(xì)粒度實體bean問題，在學(xué)生信息模塊EJB的設(shè)計中采用復(fù)合實體的設(shè)計模式。

復(fù)合實體(Composite Entity)表示、模擬和管理一組相互管理的持久性對象。持久性對象是保存在某種類型數(shù)據(jù)存儲中的對象。多個客戶端通常共享持久性對象。持久性對象可以分成兩類：粗粒度對象和依賴對象。使用“復(fù)合實體”對于一組相互聯(lián)系的持久性對象進(jìn)行建模、表示和管理，而不是按照個別細(xì)粒度實體 Bean 表示它們。復(fù)合實體 Bean 代表一個由一組對象構(gòu)成的圖。通過復(fù)合實體模式，可以減少數(shù)據(jù)庫模型的依賴性、提高網(wǎng)絡(luò)性能、消除實體間的依賴性。

復(fù)合實體模式的角色有：復(fù)合實體、粗粒度對象和依賴對象三種。其中復(fù)合實體通常是粗粒度對象或者持久粗粒度對象的引用。粗粒度對象擁有自己的生命期，管理與其他對象的關(guān)系。它可以被包含在復(fù)合實體里，同時復(fù)合實體本身可能就是粗粒度對象。依賴對象是依賴于粗粒度對象的對象，其生命期由粗粒度對象管理。學(xué)生信息模塊中復(fù)合實體的業(yè)務(wù)對象類圖如圖3所示。

圖3 學(xué)生信息模塊復(fù)合實體類圖

3.1.2 實現(xiàn)復(fù)合實體的不同策略。

實現(xiàn)復(fù)合實體模式時存在許多策略。根據(jù)學(xué)生信息模塊特點，在設(shè)計復(fù)合實體時采用了復(fù)合實體包含粗粒度對象策略和復(fù)合值對象策略和滯后加載(惰性加載)策略等三種策略。

在學(xué)生信息模塊復(fù)合實體的開發(fā)中應(yīng)用了復(fù)合實體包含粗粒度對象策略，在該策略中，復(fù)合實體(StudInfEntity)包含三個粗粒度對象(GSBaInf, USBaInf, CSUSBaInf)。粗粒度對象繼續(xù)保持與其他依賴對象(GSFamSoRel等)之間的關(guān)系。如圖3所示。

值對象是任意的可串行化Java對象。在學(xué)生信息模塊復(fù)合實體中通過應(yīng)用值對象策略(如圖 4所示)，可以創(chuàng)建必需的值對象(GSBaInf)。對于復(fù)合實體(StudInfEntity)，客戶端可以只用一個遠(yuǎn)程調(diào)用getGSBInf()來獲取全部所需的信息。根據(jù)客戶端請求數(shù)據(jù)的不同，值對象既可以是一個簡單的對象，也可以是擁有子對象的復(fù)合對象。值對象被串行化，并且按照值順序傳遞給客戶端。值對象只充當(dāng)一個數(shù)據(jù)傳輸對象；它不負(fù)責(zé)安全、事務(wù)、和業(yè)務(wù)邏輯。值對象把所有信息打包進(jìn)一個對象，使用一個遠(yuǎn)程調(diào)用來獲取信息，而不使用多個遠(yuǎn)程調(diào)用。一旦客戶端接收到該值對象，則來自客戶端的對值對象的進(jìn)一步調(diào)用相對該客戶端來說都是在本地執(zhí)行的。

一個復(fù)合對象可以由其對象樹中的多個層次的依賴對象組成。當(dāng)EJB容器調(diào)用復(fù)合實體的ejbLoad()方法時所有的依賴對象都需要加載，這個過程會花費大量的時間和資源。一種優(yōu)化策略是通過使用滯后加載策略來加載依賴對象。當(dāng)ejbLoad()方法被調(diào)用時，首先只加載那些對復(fù)合實體客戶端最關(guān)鍵的依賴對象。接著，當(dāng)客戶端訪問尚沒有從數(shù)據(jù)庫中加載的某依賴對象時，該復(fù)合實體就執(zhí)行一個即時加載。EJB2.0提供滯后加載策略。

3.2 會話外觀

3.2.1 會話外觀模式

通過把實體bean和會話bean結(jié)合在一起，能夠減少網(wǎng)絡(luò)調(diào)用等開銷，會話bean替遠(yuǎn)程客戶端執(zhí)行大批CRUD(創(chuàng)建、讀取、更新、刪除)操作。會話bean也作為一個事務(wù)的外觀進(jìn)行服務(wù)，強(qiáng)制事務(wù)在服務(wù)器上執(zhí)行，而不是牽涉到一個遠(yuǎn)程客戶端。這就把實體bean嵌入到會話bean的具體實現(xiàn)中去了。外部的客戶端永遠(yuǎn)注意不到實體bean。這種方法的最終好處是使實體bean具有高的重使用率。

采用會話外觀的設(shè)計模式把應(yīng)用邏輯(業(yè)務(wù)對象)實現(xiàn)為會話bean，商業(yè)邏輯被實現(xiàn)為實體bean。從實體bean中抽取和移動操作其他實體的業(yè)務(wù)邏輯，并集成到一個會話bean。

在學(xué)生信息模塊中，與實體bean相關(guān)的工作流被封裝在BUserSession會話bean中。會話外觀是一個粗粒度對象，其中該對象通過管理業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)服務(wù)對象交互以允許對工作流進(jìn)行封裝(如圖4所示)。

圖4 MIS系統(tǒng)學(xué)生信息管理模塊復(fù)合實體順序圖

3.2.2 總結(jié)會話外觀模式優(yōu)點

會話外觀是在MIS系統(tǒng)中使用的最多的一種EJB設(shè)計模式。即將實體bean層包裝在一個稱為會話外觀的會話bean層中，客戶端只能訪問會話 bean而不是實體 bean?？蛻舳撕头?wù)器之間的邊界被一個會話bean層分開，它的方法將映射為應(yīng)用中的所有用例，并且包含了這些用例的業(yè)務(wù)邏輯。采用會話外觀可以隱藏業(yè)務(wù)組件之間所有的復(fù)雜交互活動，向客戶端提供一個更簡單的接口。通過網(wǎng)絡(luò)跨越服務(wù)層而被直接暴露給客戶端的業(yè)務(wù)對象的數(shù)目也會減少，避免把低層業(yè)務(wù)對象直接暴露給客戶端，使兩個層之間的緊密耦合最小。采用會話外觀還可以提供統(tǒng)一的粗粒度服務(wù)層，以分離業(yè)務(wù)對象實現(xiàn)和業(yè)務(wù)對象抽象。向客戶端隱藏業(yè)務(wù)組件之間的低層交互和相互依賴關(guān)系。這樣做會提供更好的可管理性、交互(職責(zé))的集中化、更大的靈活性，以及更大的對付變化的能力。

4 結(jié)論

實體bean最適合用作粗粒度事務(wù)持久性業(yè)務(wù)組件。而使用實體 bean來表示細(xì)粒度對象會增加整體網(wǎng)絡(luò)通信和容器負(fù)載，而且將影響應(yīng)用性能和可擴(kuò)展性。為解決細(xì)粒度實體bean問題，在系統(tǒng)開發(fā)中采用了復(fù)合實體和會話外觀兩種設(shè)計模式相結(jié)合的方法，可以減少數(shù)據(jù)庫模型的依賴性、提高網(wǎng)絡(luò)性能、消除實體間的依賴性。在復(fù)合實體模式中采用了復(fù)合實體包含粗粒度對象策略和復(fù)合值對象策略和滯后加載(惰性加載)策略等三種策略，可串行化粗粒度對象和依賴對象樹。使用會話外觀可管理實體bean之間的關(guān)系，可以隱藏業(yè)務(wù)組件之間所有的復(fù)雜交互活動，向客戶端提供一個更簡單的接口。

[1](美)Floyd Marinescu著.EJB設(shè)計模式.機(jī)械工業(yè)出版社.2000.

[2]劉曉華等編著.J2EE企業(yè)級應(yīng)用開發(fā).電子工業(yè)出版社.2000.

[3](美)Deepak Alur John Grupi著.J2EE核心模式.機(jī)械工業(yè)出版社.2001.

[4](美)Ed Roman著.精通EJB.電子工業(yè)出版社.2003.

[5]Kyle Gabhart著.持久數(shù)據(jù)管理—比較Java數(shù)據(jù)對象和EJB技術(shù).J2EE探索 系列 網(wǎng)上期刊.