軟體體系架構模式在 J2EE 中的應用

層體系架構模式

層（layer）體系架構模式就是把應用系統分解成子任務組，其中每個子任務組處于一個特定的抽象層次上。

1.1 概述

層架構模式組織成一個層次結構，每一層為上層服務 (Service Provider)，同時也作為下層的用戶端。在一些層次系統中，除了包含一些輸出函數外，内部的層隻對相鄰的層可見。這樣的系統中構件在一些層實作了虛拟機（在另一些層次系統中層是部分不透明的）機制。層的調用通過決定層間如何互動的協定來定義。這種風格支援基于可增加抽象層的設計。這樣，允許将一個複雜問題分解成一個層堆棧的實作。由于每一層最多隻影響兩層，同時隻要給相鄰層提供接口，允許每層用不同的方法實作，是以為軟體重用提供了強大的支援。

1.2 問題

層結構是最成熟的軟體體系架構模式 , 它起源于早期的系統設計 , 由開始的函數調用 , 作為函數庫 , 供其他程式進行調用 . 一般在系統設計時 , 由一系列高層子產品和底層子產品處理構成 , 并且高層的子產品依賴于底層 . 是以為了完成系統的設計必須要考慮一下因素 :

• 源碼的修改會影響整個系統 , 應該被限定在一個部件内部而不影響其他子產品
• 接口應當穩定 , 甚至要被規範化
• 系統的架構應該靈活 , 可以更換
• 系統的開發需要被劃分為多個部分 , 比如團隊開發或者異地開發

1.3 模式結構

從系統高層的觀點來看設計方案比較簡單 , 它把系統進行分為幾個層次并且把它們疊加起來 , 最下面的抽象層稱為第一層 , 它是系統基礎 . 依次類推 , 把 n 層放在第 n-1 層上 . 其結構如下圖 :

1.4 非軟體描述

層模式在現實生活中很常見 . 特别在中國的封建社會的等級森嚴的制度下 , 把人分為幾個等級 , 其實就是分層 , 上層可以訓示下層 . 不過現在有的企業管理制度 , 與這種管理理念相适應的管理體制是垂直的自上而下的泛官僚體制結構。其結構設定表現為自上而下的單向層級制，這種結構有利于政令的傳達和執行，保證管理的效率 , 但是官僚特性也很明顯 . 如下圖 :

層模式在現代物流也很常見 , 如下圖的 , 在自行車在運輸的過程 , 首先在自行車廠進行出廠 , 有人員進行打包 , 然後進行裝運 , 最後再有相應的分銷商 , 進行組裝銷售 .

1.5 優點與缺點

層架構模式是最常用的一種軟體體系架構模式。從它的實作和結構圖中，我們可以得出，該模式具有以下優點和缺點 :

1.5.1 優點

• 層次的複用性 . 如果每個層次有很好的抽象接口 , 那麼它可以被其他環境複用
• 支援基于抽象程度遞增的系統設計，使設計者可以把一個複雜系統按遞增的步驟進行分解 , 使系統更容易子產品化
• 支援功能增強，因為每一層至多和相鄰的上下層互動，是以功能的改變最多影響相鄰的上下層
• 可替換性 . 因為獨立的層次設計很容易被功能相同的子產品替換

但是在實際的項目中 , 該模式也有相應的不足

1.5.2 缺點

• 低效率 分層結構通常要比單層結構的效率低 . 因為有時高層過分依賴底層的服務 , 是以必須穿過許多中間層進行資料的傳送 , 甚至多次 .
• 改變行為的連鎖反映

回頁首

層架構模式在 J2EE 中的應用

2.1 J2EE 層架構模式的背景

也許下圖大家都比較熟悉 , 它介紹了軟體從兩層體系架構方式到三層的架構模式 .

由于 2 層的架構方式 , 存在以下幾點缺點 :

• 軟體部署開銷很大 

  每個用戶端資料庫驅動都需要進行安裝和設定，一但程式發生改變，就需要重新部署，這意味巨大的開銷

• 改變資料結構的開銷很大 

  用戶端應用程式一般通過 JDBC,ODBC,ADO 等直接通路資料庫，這表明客戶程式直接與底層資料結構互動。如果改變資料結構來處理新的過程，就需要重新部署每個用戶端。

• 改變資料庫的類型的開銷很大 

  由于用戶端直接使用特定資料庫的 API, 和特定的存輸過程，觸發器等，是以資料庫類型的改變，會引起很多的修改。

但是通過把業務邏輯從存儲過程和本地的業務邏輯進行分離 , 獨立為一層 , 這樣就是應用層架構模式最經典的應用之一 .

2.2 J2ee 應用的概述

J2EE 平台為設計、開發、內建和部署企業應用提供基于元件的方法。這種方法不但能降低成本，還能對整個設計和實施過程進行快速跟蹤。J2EE 平台能提供多層分布式應用模型，能重用元件，能為使用者提供統一安全模型和靈活的事務處理控制。在 J2EE 規範中進行了以下的分層 :

• 應用用戶端元件
• Servlets 和 Java Server Pages（JSP）元件（也稱為 Web 元件）
• Enterprise JavaBeans 元件
• 基礎服務和與其他系統 ( 如資料庫等 ) 的互動

2.3 Architecture and the Cube

軟體體系架構研究者 , 把軟體系統架構進行總結和分析 , 提出了 Architecture cube 理論 . 它把一個軟體系統架構進行分解成三維進行分析 , 分别從 Tier,layer,capabilities 角度進行考慮 .

其中 Tiers 定義為 : A logical or physical organization of components into an ordered chain of service providers and consumers. Components within a tier typically consume the services of those in an "adjacent" provider tier and provide services to one or more "adjacent" consumer tiers. Within a tier, services are grouped to like requirements, such as functionality, security, or load distribution.

Layers 定義為 :The hardware and software stack that hosts services within a given tier. Physical, network, and software platforms and standard API sets support the components that provide a service. Layers, like tiers, represent a well-ordered relationship across boundaries that are mediated by interfaces. Whereas tiers represent processing chains across components, layers represent container/component relationships in implementation and deployment of services.

Systemic Qualities 定義 :The strategies, tools, and practices that deliver the requisite QoS (such as availability, scalability, security, and manageability) across the tiers and layers.

大家都知道 , 再考慮評價一個軟體體系架構是否先進時 , 我們經常要從"非功能屬性"的角度去評審 . 我們首先進行區分功能屬性和非功能屬性的差別 .

功能屬性 (function property)用來描述整個系統的功能特性 (feature), 并且通常與特定的功能需求相關 . 功能特性可以通過特定的功能使使用者可以直接看到的應用功能 , 可以通過實作來進行描述 .

非功能屬性 (non-function property)定義為解決一個軟體系統的可靠性 , 相容性 , 性能 , 易用性 , 可維護性等 .

我們的開發者過去習慣于專心提供功能屬性 , 然而今天 , 非功能屬性變得越來越來重要 .

在實際系統架構上 , 可能是每一個 Tier 上由不同的 layer 組成 , 或者說每一個 layer 都涉及不同的 Tier, 組成一個交錯的系統 , 并且 Capabilities 又和這兩者交織 , 如下圖 :

2.4 J2EE 架構的 Cube

2.4.1 Tiers

2.4.1.1 概述

如果按照 Cube 理論把 J2EE 進行分析 , 從它的 Ties 層的角度進行考慮 , 把它分為以下幾個 Tiers: 用戶端層 , 表示層 , 業務邏輯 , 內建層 , 資源層 . 每層都是按系統中業務邏輯而劃分的，它具有唯一的職責。每層與相鄰層都是松散耦合的。還可以把整個系統表示為層的堆棧。

• 用戶端層 

  該層代表通路系統的人員，應用程式，或系統的用戶端。它是整個系統的對外接口，可以是 Web 浏覽器 (IE),Java 應用程式 (Swing)，Java Applet，WAP，其他裝置或者是批處理程式。

• 表示層 

  該層封裝了用來服務通路本系統的所有用戶端的表示層邏輯。該層解釋用戶端的請求，提供單次登入，實作會話管理，控制對業務的通路（權限檢查），構造用戶端的回複 (response)，以及把回複傳遞給用戶端。一般 Sevlet,JSP 駐留在該層。

• 業務邏輯層 

  該層提供業務服務，包括業務資料和業務邏輯。通常應用程式的大多數業務處理集中在本層。同時它管理事務。EJB 駐留在該層。

• 內建層 

  該層負責與外部系統和外部資源通信，它有多種方式，如與資料庫連接配接使用的 JDBC 等 .

• 資源層 

  該層包括業務資料源和外部系統資源，如 Oracle 資料庫 ,JMS server, 其他遺留系統等 .

2.4.1.2 實作

在實作上面的 Tier 時一般我還需要結合實際情況進行分解 , 如果大家對 <J2EE core patterns> 熟悉 , 可以了解到 web 層我們使用 MVC 模式 , 當然結合 Filter,FrontControl,ViewHelp 等模式 , 客戶一般通路 JSP( 為了進行表示和業務的分離大多使用 Taglib), 然後由 Control 層進行處理 , 如果需要進行複雜的業務邏輯處理并且已經有背景實作 ( 如 EJB 等 ), 推薦經過 Business Delegate 層 , 通路後端業務邏輯 (BP), 一般業務邏輯使用 Facade 模式進行封裝成統一的接口 , 業務邏輯層實作複雜的事務處理 , 如果需要通路資源層 , 再經過 DAO 層通路資源 ( 目前多數是 RDBMS, 有時是遺留系統如 Coraba,JMS,WebService,SAP 等 ). 具體見下圖 :

關于 Intercepting Filter,Front Controller,View Helper, Business Delegate,Facade 模式請參見 <Core J2EE Pattern>。

2.4.2 Layers

2.4.2.1 概述

在開發 J2EE 應用時 , 我們一般把它縱向分為以下幾個層 , 最下層為 OS,JVM,network, 層 , 它們負責系統的底層操作和網絡資料的傳輸 , 一般我們開發人員不用關心運作在什麼具體作業系統上 , 什麼樣的網絡環境下 . 它的上層為 J2EE 服務層 , 一般由 J2EE 伺服器 ( 如 WebSphere,WebLogic 等 ) 提供各種基礎服務 , 如事務的管理 (JTS), 命名目錄服務 (JNDI), 負載均衡 (Load Balancing), 容錯 (failover), 安全 (security) 等 , 其次是通用業務層 , 它一般完成與具體業務無關的基本操作 , 包括如基礎的架構 (Framework),commons 元件 , 如通用的資料庫處理元件 , 系統錯誤處理元件 , 字元處理和數值處理元件 , 日志 (log) 處理 , 資料轉化和編碼維護等核心層 . 最上層才是我們的具體業務邏輯子產品 , 它完成具體的業務邏輯 . 具體見下圖 :

2.4.2.2 實作

結合 J2EE 實際環境 , 最底層一般不需開發人員關心的作業系統和網絡環境 , 并且不同 J2EE 服務廠商都提供了相應 J2EE 所必須得基礎服務層 , 我們開發人員一般隻需關心上面兩層的實作 , 應用服務層經常使用類似于 struts,webwork,waf 等的 web application framework,log 服務一般選擇 log4j.commons log 等 , 其他具體的資料處理 , 資料的轉化等操作我們需要進行開發 , 不過這些一般與具體項目無關 , 可以在公司内部不同的項目之間共享 . 其實 Jakarta Commons 提供的功能一般可以使用在該層 . 最上層才是我們的具體業務子產品 . 見下圖 :

2.5 層模式實作讨論

1. 為把任務分組成層而定義抽象準則。
2. 根據抽象準則定義抽象層數。
3. 給每個層命名并指定它們的任務。
4. 指定服務
5. 細化分層
6. 為每個層指定一個接口。
7. 建構獨立層。
8. 指定相鄰層間的通信 ( 或者調用 )

回頁首

Petstore 的層架構模式

3.1 PetStore 概述

PetStore 是 Sun 公司在 J2EE 平台上開發的一個應用樣例，是 Java 軟體在 J2EE 的藍圖程式，它示範了如何利用 J2EE1.3 平台的性能去開發靈活、可更新的分布式平台企業應用系統。PetStore 是一個運作在 Web 上的，為網絡客戶提供寵物資訊浏覽、網上訂單和管理等功能的網上寵物店，在技術上使用了 J2EE 中的大部分企業元件和優秀的設計模式，提供了一套有高靈活性擴充性和可更新的完善 J2EE 開發架構 .

PetStore 共有 4 個子系統組成 :

• petstore Web Site 該部分是 petstore 中的核心，客戶登入系統進行選擇 , 定購 , 送出定單等。
• petstore admin 該部分是系統的管理功能
• Order processing center 定單排程中心 , 對客戶送出的定單進行處理
• PetStore supplier 為産品供應者提供的維護畫面

在這裡主要以 WebSite 為主進行分析 ( 以下 petstore 均指該子系統 ), 它是怎樣進行分層處理的 .

3.2 Petstore 體系架構

我們按照層的架構模式進行分析 , 主要從 Tiers 和 layer 角度進行考慮 .

3.2.1 Layer 層

3.2.1.1 概述

PetStore 是基于 Web 應用系統 , 它的用戶端使用 Broswer, 然後是 Web 層的應用 , 業邏輯的層 ( 由 EJB 實作 ), 資源管理層 ( 包括資料庫 ,JMS,JavaMail 等 ). 具體又細分為以下幾層 .

• 客戶請求浏覽頁面 , 一般 Web 層的 View 由 JSP 組成 , 并且使用了大量 Taglib
• 把每個請求映射到某個 HTMLAction 類 , 來響應它 .HTML Action 類是一個标準的類 , 執行選擇的 HTML Action
• WCC 是由 WebClientController 完成 ( 實作類為 WebClientControllerImpl), 它實際是 SUN 核心模式的 Business Delegate 層
• ECC 是 EJBClientController, 它實際是核心模式 Session Facade
• EjbAction 層執行 EJB Action, 傳送 event 參數進來 .EJB Action 讀 event 裡面的參數 , 并且操縱 EJB 或者别的資料源來執行相應的商業操作 .
• 業務內建層 , 由通過 DAO,EntityBean,JMS 等通路相應的資源 .

具體的詳細的結構如下 :

3.2.1.2 實作

在 Web 層它應用了著名的 MVC 模式 ,V 由 JSP 來實作 , 為了業務邏輯和表示的分離 , 一般結合 JSPTagLib. 它把請求送出到相應的處理 MainServelet, 然後準發到 RequestProcessor, 他根據讀取 mappings.xml, 的配置資訊 , 生成相應的處理類 Action 如

<url-mapping url="createuser.do" screen="create_customer.screen" 
    isAction="true"> 
    <action-class>
    com.sun.j2ee.blueprints.petstore.controller.web.actions.CreateUserHTMLAction
    </action-class> 
   </url-mapping>      

每個 Action 一般包括以下幾種方法 (doStart, perform, doEnd), 如果 perform 隻需對請求的處理 , 如果處理的結果不需調用 EJB 的業務邏輯 , 隻需傳回即可 , 否則把請求組織成相應的 Event, 通過 WCC 轉發到背景的業務邏輯層 . 代碼見下 :

public void processRequest(HttpServletRequest request) throws HTMLActionException,
	EventException, ServletException { 
    Event ev = null; 
    String fullURL = request.getRequestURI(); 
    // get the screen name 
    String selectedURL = null; 
    ServiceLocator sl = (ServiceLocator)request.getSession()
		.getAttribute(WebKeys.SERVICE_LOCATOR); 
    WebClientController wcc =  sl.getWebClientController();
    HTMLAction action = getAction(selectedURL); 
    if (action != null) { 
         action.setServletContext(context); 
         action.doStart(request); 
         ev = action.perform(request); 
         EventResponse eventResponse = null; 
         if (ev != null) { 
               eventResponse  = wcc.handleEvent(ev);
         } 
         action.doEnd(request, eventResponse); 
    } 
}      

通過 WCC 把 Event 轉發到 EC, 這裡 WC 是 delegeteBussiness 層

public class WebClientControllerImpl implements WebClientController { 
    public synchronized EventResponse handleEvent(Event ev) 
        throws EventException { 
            return ccEjb.processEvent(ev); 
    } 
 } 
 EC 是 Facade 層 , 如下 , 
 public class EJBClientControllerEJB implements SessionBean { 
 protected StateMachine sm; 
    public EventResponse processEvent(Event ev) 
        throws EventException { 
          return (sm.processEvent(ev)); 
 } 
 }      

然後根據相應的 Event 的類型使用不同 EJBAction 來完成相應的業務邏輯 ,

public EventResponse processEvent(Event ev) throws EventException { 
        String eventName = ev.getEventName(); 
        String actionName = null; 
        EventResponse response = null; 
        if (eventName != null) { 
            actionName = getActionName(eventName); 
            EJBAction action = null; 
            action = (EJBAction)Class.forName(actionName).newInstance(); 
            if (action != null) { 
                action.init(this); 
                // do the magic 
                action.doStart(); 
                response = action.perform(ev); 
                action.doEnd(); 
            } 
        } 
        return response; 
    }      

每個具體的 EJBAction 完成自己的具體的業物邏輯 , 如果處理資料對象 , 則使用的相應的實體對象 (data module). 具體的層次調用過程 , 見下圖 :

3.2.2 Tier 層

3.2.2.1 概述

PetStore Layer 的設計分為以下幾層 , 最底層為作業系統和網絡服務 , 然後是基于 J2EE 伺服器提供的系統服務層 , 上面是 framework,Component 層 , 包括 WebApplicationFrameWork, 以及 commons 業務邏輯 , 工具類等組成 . 最上層才是具體的業務實作子產品具體見下圖 :

3.2.2.2 實作

Petstore 主要開發了兩層 , 其中業務核心層 , 主要有幾部分

• WAF (Web Application Framework)
• ApplicationControl 和 Presentation ( 主要指 JSP TagLib)
• Components( 如各種實體對象如 customer,Account, 等 )
• Business Logic Data 各種常用的工具類

層的業務邏輯包括以下幾個部分 :

登入和注冊 , 購物車子產品 , 登入子產品等

我們以 WAF 為例介紹業務共同層的作用 , 開發者 , 可以基于這個架構 , 添加自己的代碼和實作 , 下面紅框内為 WAF 核心 , 如果增加新的業務功能隻需增加相應的綠色部分 .

同時其他的 components 提供了對 JMS,Mail 等的處理 .

回頁首

相關設計模式

4.1 外觀模式 (Facade)

外觀模式的意圖就是為子系統中的一組接口提供一個一緻的界面，Facade 模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。

其實層模式的每層之間的經常使用 Facade 來進行封裝成一緻的接口供上層進行調用 . 如 PetStore 的 EJB 層的 ECC 就是 Facade 模式的應用 .

public interface EJBClientController extends javax.ejb.EJBObject { 
    public EventResponse processEvent(Event ev) throws EventException, RemoteException; 
 }      

J2EE 核心模式的 SessionFacade 模式定義了一類高層的業務元件，用于封裝并集中較低層次業務元件之間的複雜互動。它為用戶端提供單一接口，用于通路應用程式或應用程式子集的功能。它還把較低層次的業務元件彼此分離開來，進而使設計更具靈活性和可了解性。通過遠端接口的細粒度通路是不可取的，因為這會增加網絡通信量和滞後時間。多個細粒度調用會産生許多網絡通信，而且會降低性能，因為遠端調用的滞後時間很高。引入 Session Facade 會減少網絡通信和滞後時間，因為對細粒度業務對象的所有通路都是本地的。見下圖 :

4.2 中介模式 (Mediator)

外觀模式的意圖就是用一個中介對象來封裝一系列的對象互動。中介模式使各對象不需要顯式地互相引用，進而使其耦合松散，而且可以獨立地改變它們之間的互動。在層架構模式中有時會使用該設計模式 , 使層之間的通信僅知道中介者并且隻與通信 , 而不是層直接調用其他系統 . 使用中介模式如下 :

回頁首

總結

本文介紹了軟體體系架構模式的層模式 , 分析了它的結構 , 特點 , 實作 , 以及優缺點 . 然後介紹遵循層模式的 Architectural cube 理論 , 結合 J2EE 的體系架構特點 , 剖析層模式是怎樣應用的 . 最後以 PetStore 為例 , 簡單闡述怎樣應用該模式在實際 J2EE 系統之中 .

參考:http://www.ibm.com/developerworks/cn/java/l-tier/