J2EE分佈式系統框架設計

J2EE分佈式系統框架設計
	發佈者： 發佈時間：2007-01-01
一，導言 框架設計（Framework Design）是系統設計的重要組成部分，一個設計優秀的框架是一個可擴展和可改變（遷移）系統的基礎。本文針對常見J2EE分佈式的信息系統（特別是B/S形式的系統），提出作者在框架設計上的觀點和思路。 （一）問題和解決方法 目前應用J2EE技術構建信息系統的需求越來越複雜，開發週期越來越緊迫，同時對系統的穩定性、擴展性和可維護性要求也越來越高。那麼如何滿足客戶對系統要求，加快我們的開發呢？信息系統需要一個持久化的存儲設備（如：數據庫）中存放和取回信息數據。當存儲設備改變時，我們如何使系統支持這個改變，而不用重寫我們的程序代碼呢？已有的代碼能不能在新的系統上重用呢？類似問題，給我們系統設計帶來很大的挑戰。 一個有效的解決方法是把信息業務信息按照應用功能模塊拆分開：業務邏輯與數據庫服務器分開，用戶界面與業務邏輯分開。闢此相對獨立，任一方任何改變都不會影響對方。這就是我們經常提到的三層概念。 *表示層（Presentation） *業務邏輯層（Business Logic） *數據存儲層（Data） 表示層負責提供用戶界面，業務邏輯層負責實現業務邏輯，數據存儲層負責業務邏輯層中所有數據的持久的存儲。 業務邏輯層在三層模型中具有很好的伸縮性，設計者往往根據系統容量、分發、部署等等情況再一步把業務邏輯層細分，從而產生了多層。這就是所謂n層體系結構。所以業務邏輯層也是我們系統設計中最重要的一塊。 引入三層模型後，我們就可以針對這三層的特點定義出一種可重用的、可擴展的類集合，它通過標準的API來先外提供服務。這些類集合的劃分和定義過程就是我們所要闡述的框架設計。 （二）框架定義及特點 什麼是框架（framework）？框架可以定義爲一組關係服務的可擴展、可重用的子系統。常見的軟件框架有：MFC、VCL、JDK等等。其具有以下的特點。 *它是一個功能類的集合，類之間可以相互協作，爲業務邏輯子系統提供服務。 *它包含了具體類和抽象類，這些類定義了標準的接口、對象間的交互作用和系統的相關常量。抽象類，可以包含抽象和具體的方法。 *爲了利用、自定義或擴展框架的服務，通常需要框架的使用者去定義已存在的框架類的子類。 *框架中定義好的類只提供給用戶自定義的類調用，而從不調用用戶自己定義的類。 二，框架設計 對於一個分佈式信息系統，我們通過上面的討論，引入了三層的設計模型，現在就可以在這個模型上進行系統的框架設計了。但是，在開始設計之前先明確一下框架設計的目標。根據系統要求和框架定義，我們的目標爲： *類（組件、代碼）最大化的重用。 *框架結構儘可能合理、簡單和明瞭。 *框架要有靈活擴展性。滿足用戶的二次開發要求。 *框架要安全、穩定、高效率，可維護，可升級。 *框架中子系統（包）之間不應該存在雙向性依存關係。 分佈式信息系統三層設計模型中系統類的類型（Classes-Type）體系結構圖如下所示： 圖（一） 所以此框架設計爲： 把分佈式信息系統的框架總體劃分爲四個主體包，分別爲：表示層的用戶界面包（ui），業務邏輯層的業務對象包（bs），數據持久層的數據持久包（ps），系統資源層的通用實用包（su），結合公司自己的命名規範，具體的UML框架圖可爲如下所示：   圖（二） 其中，“ProjectName”爲信息系統項目的立項英文命名，如：國有資產管理系統，“ProjectName”爲“sams”；“CompanyName”爲公司的英文簡稱，如：翱拓系統集成，“CompanyName”爲“auto”。 “ui”----用戶界面包（User Interface）。 “bs”----業務邏輯包（Business Session）。 “ps”----數據持久存儲包（Persistence Store）。 “su”----系統通用實用包（System Utility）。 下面將結合J2EE體系結構分別詳細討論各層包的框架實現問題。 （一）通用系統資源層框架設計 通用系統資源層框架設計，從我們上面定義好框架來看就是系統通用包su（System Utility）的設計。從圖（二）可以看出，ui包、bs包和ps包都是從su包中調用接口，su包給它們提供服務。所以本層框架的設計是系統能否實現類（組件）重用的基礎，是系統能否滿足可靠穩定、高效率和可維護的關鍵。 既然是通用包，那麼它具體提供哪些服務（或工具）呢？我們知道J2EE體系結構中也提供了許多標準的服務，如：JMS、EJB、JTA等等。那麼su包是否也應該提供類似的服務呢？這些問題都沒有統一的答案，這主要看項目系統分析和設計人員根據項目本身的特點和需求，應用什麼樣的技術和解決問題所運用什麼樣的設計思想和設計模式等因素有關。 值得一提的是，“框架是骨架，設計模式是肉”。設計模式思想影響框架的構成，一個框架中應用合適的設計模式來實現，纔是框架精華的所在。在這一層，常應用到的設計模式有：結構型的Bridge模式、Facade、Proxy；創建型的Factory、Singleton和行爲型的Strategy等。 根據作者的經驗，結合J2EE體系結構的應用，通用系統資源層的框架可爲： 圖（三） 圖（三）說明如下： su包包含8個子包，分別爲： （1），resource包，包含標準接口訪問J2EE中間件（應用服務器）資源的類。如：容器的JNDI服務等等。 （2），factory包，包含創建不同類型對象的接口的類，目的是有利於控制類創建，減少一些關鍵對象誤用的風險。 （3），jms包，包裝了有關應用J2EE消息服務的類。 （4），ui包，針對表示層封裝一些標準通用的類。 （5），ejb包，引用Bridge設計模式，在EJB中加多一層封裝，一般以後方便擴展和維護EJB，減少ejb編程的風險。根據ejb的類型，分session和entity兩個子包。 （6），db包，包含有關訪問數據庫的類，包括：數據庫連接池、報表和序列號等標準接口。 （7），log包，包含記錄體統日誌和調試應用的接口類。細分applog和appdebug兩個包。 （8），exception包，根據系統的特性，自定義一套應用異常。 （9）tools包，包含了常用標準的系統函數類。根據這些函數的類型，分爲：date、maths、format和constfunc四個包。 以上框架僅爲參考，設計人員可根據自己的實際需要，來重新定義。 （二）表示層框架設計 表示層框架設計對應着我們定義的ui包框架設計。在針對J2EE體系結構做系統設計時，往往應用MVC（Model-View-Controller）設計模式來實現。MVC模式根據應用的角色對應用進行分解，然後使用不同的方法解決。 *Model，模型，系統應用的具體數據模型，不關心怎麼表示和何時訪問。只考慮數據的完整性和存儲方式。與數據持久層對應，所以是我們數據持久層框架設計所關心的問題。 *View，視圖，只關係如何表示的問題。本層討論。 *Controller，控制器，控制器是解決何時訪問的問題。是系統應用的業務邏輯，確定是否滿足一定條件時，應用程序才能訪問模型（Model）中的特定數據，然後根據情況把取得的具體數據委託給負責表示的視圖（View）。與業務邏輯層對應，在業務邏輯層框架設計中討論。 在J2EE體系中，AWT、SWING、JSP和Servlet都是針對表示（視圖）而設計的。在實際應用中，我們經常根據系統不同的功能模塊寫JSP和APP客戶端應用程序來和用戶交互，所以在框架定義中可分爲兩個包，jsp包和app包；同時，有時候還需要定義一些系統常量和處理一些頁面邏輯，所以我們也定義一個vbn（view bean）包來存放這些頁面類和常量類。所以表示層的框架設計可爲： 圖（四） 圖（四）說明如下： （1）jsp包，按信息系統不同的功能模塊存放jsp程序文件。由於jsp文件類型不是java文件類型，所以此包可以當作目錄處理，把其提出來，按照系統部署的要求，單獨放在一個合理的目錄下。其中JFunctionModule1、JfunctionModule2、JfunctionModule3等名稱爲信息系統具體的功能模塊名稱。可根據需要來定義和安排目錄。 （2）app包，存放java客戶端應用程序。其中AFunctionModule1、AfunctionModule2、AfunctionModule3等包名稱爲信息系統具體的功能模塊包名稱。根據客戶端應用程序的所屬關係，存放到具體的功能模塊包中。 （3）vbn包，存放信息系統表示層的常量定義類和頁面處理類。 最後，值得一提的是：在表示層的jsp頁面開發中，爲了避免把太多的代碼和邏輯編寫在同一個頁碼中，提高jsp程序的效率和可維護性，可以應用VC（View-Controller）設計模式，html爲視圖，servlet爲控制器。當然還可以應用struts技術來實現，這裏就不在討論了。這應該屬於具體的程序設計問題。   （三）業務邏輯層框架設計 業務邏輯層設計對應我們定義bs包的框架設計。是MVC模式的Controller（控制器），負責訪問數據持久層，把返回數據提交給表示層，起到承上啓下的作用。J2EE體系結構中，我們一般應用會話Bean來實現。 業務邏輯層設計在系統設計的詳細設計中是最爲複雜，工作量對大的一塊。需要從系統分析中提取信息系統各個功能模塊的用例（Use Case），再針對每個用例，應用UML語言詳細繪畫出此用例的順序圖（或協作圖），然後根據實際情況決定是否使用有狀態還是無狀態的會話Bean。但是，此層的的框架設計卻簡單明瞭，其框架可爲： 圖（五） 在bs包下直接根據信息系統的功能模塊的名稱來定義子包。其中，bsFunctionModule爲功能模塊的英文名稱。   （四）數據持久層框架設計 數據持久層對應MVC設計模型中的Model，其設計是信息系統設計的最重要部分，是系統的性能和是否可平移的基礎，其設計好壞直接影響到項目的成功與否。數據持久層框架設計只有詳細討論數據模型設計後，才能比較好勾畫出來。故本節準備探討持久數據模型設計後，再實現其框架設計。 ◆常見數據持久層設計類型 （A）在業務邏輯層的類中，直接使用SQL代碼。如下圖所示：   圖（六） *優點： 寫代碼的效率很高。 *缺點： SQL代碼到處出現在程序的類中；邏輯業務類與數據庫直接耦合在一起，這意味着任何小的改動都導致程序原代碼的修改。    *結論： 對於小型應用程序是可行的，對於企業級的系統，這種在邏輯業務類中寫死SQL的方法，會導致代碼難於維護和擴展。 （B）SQL代碼封裝在一個或多個數據代理類中。如下圖所示： 圖（七） *優點： 在業務類和數據庫之間加多一層封裝，是系統的可維護性大爲提高。這種方法包括可以利用數據庫存儲過程、SQLJ以及微軟ADO數據訪問的策略。 *缺點： 對數據庫進行任何一點的改動都會直接影響到數據代理的代碼，也就是程序原代碼還必須改動。 （C）不用寫SQL代碼，對數據庫的訪問完全通過具有魯棒性數據持久層來實現。如圖所示：   圖（八） 所謂的魯棒性數據持久層至少要滿足下面的條件： （1），支持關係數據庫的高級的特性。（如：事務、存儲過程、遊標） （2），支持對象和關係之間的映射，用戶不直接用SQL與數據庫交互。 （3），支持多連接，支持數據庫連接池。 （4），支持多種體系結構，支持不同廠商的數據庫。 *優點： 應用程序開發人員不需要了解數據庫結構，甚至也沒必要知道對象如何保存在數據庫的。有利於組織開發大規模的針對關鍵業務的信息系統。系統的遷植性、可維護性和擴展性好。 *缺點： 由於對數據庫的訪問交給了持久層處理，理論上對系統的性能上有些影響。 ◆具體選型 上面列出了常見的數據持久層的幾種類型，那麼我們究竟應用那種類型比較合適呢？這需要根據系統規模和需要的具體情況來決定。在J2EE體系結構中開發系統，我們應該選擇（B）和（C）兩種數據持久層比較合適。 在J2EE體系結構中，類型（C）魯棒性數據持久層可以應用EJB的容器管理實體Bean（CMP）來實現，在EJB2.X中CMP就是爲了實現魯棒性數據持久層而制定的標準規範。開發人員不必在CMP中編寫SQL代碼，一切和數據庫的交互都交給EJB容器去負責。由於J2EE是開放、標準規範，所以，CMP組件可以在EJB容器與數據庫之間移植。 在實際的信息系統開發過程中，我們往往需要處理一些複雜的查詢或報表，而這些查詢數據往往來源於多個數據表，而且其查詢結果的實體對象的觀念性不強。這個時候，我們用CMP去封裝它就顯得有點無能爲力了。因爲理論上實體Bean畢竟代表了數據庫表裏面的一行數據。 遇到這種情形，數據持久層的設計採用類型（B）就比較合適了。我們可以用EJB的無狀態會話Bean來實現這層的封裝。通常的利用Bridge設計模式來實現： （1）建立數據訪問對象DAO（Data Access Object）接口。定義數據源的抽象操作行爲，提供方便訪問和維護數據的標準API結構。 （2）實現數據訪問對象接口。DAOImplementor。實現具體DAO接口的內容，根據應用的數據源類型不同，可以有針對多個數據源的實現（如：DAOImplementorSQLServer，DAOImplentorOracle等等）。然後應用Adapter設計模式，將特定的數據源驅動接口分配到DAO中去。 （3）建立EJB調用DAOImplementor，實現業務邏輯。 如下圖所示：   圖（九）     ◆框架設計 通過，上面的討論，我們數據持久層（ps）包的框架可爲：   圖（十） ps包下按信息系統的功能模塊來劃分子包（如：上圖分了3個功能模塊包，PfunctionModule1、PfunctionModule2和PfunctionModule3），每個功能模塊包再分： be（business entity）包，包含業務實體對象（數據庫關係映射對象），DAO定義接口等等。 eb（entity bean）包，包含實現數據持久層的實體組件。 sb（session bean）包，包含實現數據持久層的會話組件。     三，概述 系統框架設計不是一成不變的，往往根據系統設計師的對某個信息系統的見解不同，框架也有所差別。但是要設計一個好的框架，除了有明確的設計目標外，關鍵在於：需要調查和研究系統同類產品的狀況及相關的技術特點，瞭解目前流行技術對此產品所能提供理論和技術支持情況，結合自己產品的特點，才能逐步勾畫出整個產品項目的框架藍圖。     四，參考書目 《Mastering Enterprise JavaBeans》Ed Roman 《Design of a Persistence Layer Series》 《UML和模式應用》Craig Larman     關於作者： 餘浩東，擅長數據集成的軟件工程師。目前他和他的Boby（一隻貪吃公狗）住在深圳羅湖的一個小山莊，他的興趣包括與分佈式計算和軟件工程相關的一切技術，以及攝影、爬山、游泳等運動。他的e-mail是：[email protected]