信息管理系統中實體bean問題之解決方案研究

閆寶華

甘肅民族師范學院 甘肅 747000

0 引言

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

1 信息化管理系統(MIS)整體架構設計

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

圖1 MIS系統整體架構設計(BS和CS混合結構)

2 MIS系統中數據模型的分析

2.1 模型分析

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

圖2 某MIS系統學生信息管理模塊實體關系圖

2.2 細粒度實體bean問題

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

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

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

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

3 在MIS系統中的解決方案

3.1 把實體 bean設計并實現成具有根和依賴對象的粗粒度對象——復合實體

3.1.1 復合實體及其相關概念

如果把學生信息模塊的對象模型直接映射到實體bean，將導致大量的細粒度實體bean。從而帶來網絡負載、數據庫模式依賴及管理復雜等問題。為解決細粒度實體bean問題，在學生信息模塊EJB的設計中采用復合實體的設計模式。

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

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

圖3 學生信息模塊復合實體類圖

3.1.2 實現復合實體的不同策略。

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

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

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

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

3.2 會話外觀

3.2.1 會話外觀模式

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

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

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

圖4 MIS系統學生信息管理模塊復合實體順序圖

3.2.2 總結會話外觀模式優點

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

4 結論

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

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

[2]劉曉華等編著.J2EE企業級應用開發.電子工業出版社.2000.

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

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

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