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]