步入J2EE架構和過程

標  題: 步入J2EE架構和過程
發信站: BBS 水木清華站 (Fri Apr 26 16:02:08 2002)

本文轉自賽迪網開發者 developer.ccidnet.com

摘要
Java2企業版（J2EE）平臺由四個關鍵部分構成：規格說明、參考實現、兼容性測試套件
和藍圖（BluePrint）計劃。藍圖描繪了分佈式組件架構最好的實踐和設計指導方針。本
文基於Rational統一過程和BluePrint示例程序介紹一個八步驟J2EE開發方法學。通過閱
讀這篇文章，你可以瞭解許多重要的J2EE架構的話題，並且能夠擴展和修改這個簡單的
方法來解決自己特有的業務問題。
在商業世界裏，我們使用Java2 企業版（J2EE）解決業務問題、開發商業軟件或者提供
轉包服務。如果一家公司想使用多層體系結構建造一個電子商務網站，通常在整個開發
生命週期中需要涉及到管理者、架構師，設計人員、編程人員、測試人員和數據庫專家
。
爲了使不同部門能高效率地工作，他們經常需要一個軟件開發過程。一些經典的開發過
程包括瀑布模型、快速應用開發（RAD）和極限編程（XP）。本文我們將集中於一個流行
的軟件工程過程，即Rational統一過程（RUP）。RUP提供了一個給角色分配任務和責任
的嚴格方法。它的目標是保證我們在預期的進度和預算內開發出滿足用戶需求的高質量
軟件。
我在J2EE開發中使用RUP出於以下三個原因。首先，RUP以架構爲中心；在將資源分配給
全面開發之前，它先開發一個可執行的架構原型。其次，RUP是迭代並基於構件的。該架
構基線通常包括一個框架或基礎設施以便於通過迭代增加構件，在不影響系統其他部分
的前提下定製和擴展一個系統的功能。最後，RUP利用一門工業標準語言--UML，可視化
建模系統的架構和構件。RUP有四個不同的開發階段：初始、細化、構造和移交。然而，
本文從技術角度覆蓋了J2EE開發的八個必要活動，主要集中在系統架構。
1、 需求分析
需求分析描述系統應該做什麼或不應該做什麼使得開發者和客戶可以簽署一份原始的商
業合同。可以使用業務概念、領域術語、用例和用戶界面（UI）模型形成功能需求文檔
。對於非功能需求，如性能和事務，可以在需求文檔附件中詳細說明。根據參與項目深
度的不同，確定在紙上還是使用HTML建造高層UI模型。
圖1 展現了一個典型電子商務系統中的兩個用例。查看訂單（viewOrder）用例告訴我們
一個用戶通過Web界面登陸系統、查看訂單列表，點擊鏈接查看特定訂單的詳細信息。增
加訂單項（addLineItem）用例告訴我們瀏覽產品列表、選擇感興趣的產品並將它們添加
到購買訂單中。
圖1 訂購用例
2、 面向對象分析
分析人員構造問題領域模型：類、對象和交互。分析應該與技術和實現細節無關，幷包
含一個理想的模型。對象分析可以幫助理解問題並獲得關於問題領域的知識。因爲業務
過程的改變比信息技術的改變要慢得多，所以必須要維持一個不含技術細節的純領域模
型。
這兩個步驟--需求分析和麪向對象分析--不是J2EE特有的；對許多面向對象方法學來說
，它們都非常通用。圖2 顯示了一個寵物店示例程序的高層對象分析模型。它用圖例說
明瞭我們從需求分析用例中識別的主要概念。我們把這些概念建模成對象並標識它們的
關係。
圖2 更高層分析模型：寵物店領域
需求和對象分析的結果是爲J2EE架構的開發提供切入點。爲了開發架構，可以選擇一個
縱向聯合部分（vertical piece）--經常是關鍵部分，如訂單領域對象模型--進行對象
設計、實現、測試和部署。（縱向聯合部分，一個RUP概念，是指系統的一小部分。起始
點是圖1所示的用例子集和圖3所示的領域分析模型。一個縱向聯合部分的實現結果是一
個全功能的微小系統，包括UI層的JSP，中間層業務對象如EJB和後端數據庫。）可以將
從原型中獲得的經驗應用於領域對象並作爲對象設計階段的指導。
圖3 詳細對象分析：訂單
3、 架構規格說明
經過前面兩個步驟，業務領域問題和需求應該比較明確了。現在，我們將工作集中在技
術策略和架構上。架構是指所有構件組合定義系統的一個藍圖：結構、接口和通訊機制
。我們可以進一步將架構分爲企業級和應用級架構。
企業級系統架構
企業級系統架構包括硬件和軟件基礎設施、網絡佈局、開發、測試、生產環境等等。它
反映了一個企業的長期投資。開發前，需要評估已存在的軟件和硬件基礎設施，如果不
完全支持J2EE的話，增加新構件更新已存在系統。你需要徹底地評估硬件，包括計算機
、路由器、網絡轉換器和網絡佈局，因爲它們都影響到系統的性能和可靠性。圖4 顯示
了一個可能的多層網絡佈局。
圖4 企業級架構：網絡佈局
如圖4所示的一個多層企業級架構包括以下幾個主要構件：
一個Web瀏覽器客戶端，可能在也可能不在客戶端組織的防火牆內
一個HTTP服務器，是一個對公衆開放的Web服務器。它通常位於一個稱作DMZ的子網內
Web容器主表示層和可能的業務邏輯構件
應用程序容器主業務邏輯構件
關係數據庫管理系統（RDBMS）和數據庫主數據、數據邏輯
你使用的系統架構類型依賴於安全、性能和可靠性的需求，也依賴於組織的財政狀況。
在缺少經驗的情況下，也可以適當地從一個修理廠電話訂購一臺簡單地二手計算機。In
ternet上有許多開放源代碼的操作系統、Web服務器、應用程序服務器和數據庫管理系統
。得到這些系統的代價只是幾百美元和熬幾個通宵。
象許多華爾街金融機構這樣的高端客戶也許需要一個連續支持安全、高吞吐量交易和不
可預料網絡通訊的系統。在這種情況下，爲了容錯，通常需要將Web服務器和應用程序服
務器集羣配置成一個n層架構。
還需要評估軟件基礎設施，包括Web服務器、安全管理軟件、應用程序服務器、域名管理
服務器、數據庫管理系統和第三方軟件構件。如果還沒有購買應用程序服務器，選擇一
個J2EE供應商將是評估過程的一個重要方面。應該注意到不同的供應商對J2EE的實現程
度是不同的，一些供應商只支持老的J2EE版本。另外，一些Web容器或應用程序容器可能
比其他的速度要快。除了實現J2EE規範外，許多供應商還出售J2EE基礎構件或框架。選
擇一個穩定的提供支持的J2EE供應商也非常關鍵。你可以在系統基礎設施層面上購買或
開發的通用功能包括：
事務
國際化和本地化
集羣和對象分佈
應用程序性能度量和剖析
通訊
工作流管理
入口和個性化管理
層對層通訊協議
安全和防火牆
應用架構
應用架構參考一個特定的項目和規範建立在企業級系統架構的上層。在基礎設施完成後
，架構師研究怎樣構造一個特定的應用。如果你的企業級架構僅部分支持老的J2EE版本
，可以先升級你的系統。如果由於預算或時間關係不能升級，那麼必須在更老版本規定
的技術範圍內開展工作。雖然構造企業級重用構件非常重要，但是必須首先要能夠使用
。這裏的最終目標是滿足客戶的需求--一次一個項目。
架構師不是設計師；架構和設計是完全不同。一個應用架構的範圍包括系統的主要結構
、架構設計模式和可以在上面增加構件的框架。架構主要關注的是非功能性方面，而設
計關注應用業務用例將領域對象模型轉換成技術對象模型。應用架構是項目的結構，一
個特殊的應用程序。通過應用架構開發，你通常必須要做的應用架構決定包括：
層之間進行功能劃分
領域對象建模
要保護的遺留系統
要購買的軟件構件
要開發的構件
怎樣集成第三方構件
圖3的訂單領域對象說明了怎樣對領域對象進行建模。利用當前的Java技術，可以將領域
對象分佈在作爲開發者管理持續性對象的Web容器中、應用程序服務器的EJB中或者作爲
RDBMS宿主的Java存儲過程中。
在寵物店藍圖中，我們將訂單對象設計成一個實體bean，一個詳細對象和一個數據訪問
對象，如圖5和後面的圖6所示。當你看到這個的時候，你應該意識到架構的重要性。爲
什麼分析模型中的一個領域對象映射成這麼多對象？如果改變設計，會出現什麼問題？
你也許聽說過EJB的好處，但是要注意不同供應商的性能是不同的。當一種新技術到來的
時候，你需要在投入全面設計之前進行一些研究。你可以經常地將設計和實現領域對象
模型縱向聯合部分的經驗應用到其他許多領域對象中。這就是架構開發的內容。
圖5 訂單對象設計模型
在J2EE的早期，一些面向對象的設計人員試圖將領域模型映射成實體bean並通過層傳輸
。它們包含很好的UML圖，但結果是由於不必要的網絡通訊使得系統運行很慢。沒有架構
開發，沒有清楚地理解一種新技術就從對象分析直接轉到對象設計往往導致項目失敗。

架構可交付產品
由於J2EE架構是一個相對新的話題，對於J2EE架構師的可交付產品還沒有很好的定義。
從寵物店示例程序來說，很難區分架構在哪裏停止，設計又在哪裏開始。文檔隨應用架
構的高層檢查、模型-視圖-控制設計模式的討論和架構總覽開始。低層文檔在源代碼中
。這裏沒有UML圖。Sun的J2EE企業架構師認證的委派部分要求所有產品用UML表示。然而
，標記只表示類圖、構件圖和少量對象交互圖。這些對真實世界裏J2EE應用來說遠遠不
夠。架構規格和過程至少需要下面的東西：
一份描述現存硬件、軟件、網絡佈局和其他構件的系統架構文檔
一份描述現存硬件、軟件、網絡佈局和其他構件的系統架構文檔
一份描述應用程序主要結構，包括所有重要結構構件、用例構件和遺留構件邏輯視圖的
應用架構文檔
一份如果有其他選擇的情況下，描述所有設計指導和架構決定，解釋這些決定並描述可
能結果的新構件設計指導。這些指導應該捕獲所有重要的基礎決定因素，新構件設計必
須考慮維護系統架構的完整性。
一個正在運轉的架構原型，可以評估新技術；獲得開發和部署J2EE應用程序的經驗；構
造架構框架；度量性能、可伸縮性和易用性來說明風險；還可以向項目承擔者證明你的
方法是可行的。
在開發了幾個J2EE解決方案得到更多經驗之後，原型變得不太重要，少量的UML圖和一些
設計指導或許就足夠了。
4、 對象設計
在架構規範的指導下，設計從技術上擴展和修改了分析結果。雖然分析階段的領域對象
建模應該與技術細節無關，但是對象設計完全依賴於技術因素，包括平臺、語言的類型
和架構開發階段選擇的供應商。分析時，擡頭望着星星，但在設計階段，則要腳踏實地
。理論上，爲了維持業務對象的基本屬性和行爲，除非絕對必要，不應該破壞它們。
在架構結果的指導下，詳細設計工作應該說明所有類的規格，包括必須實現的屬性、它
們的詳細接口和僞代碼或操作的純文本描述。規格說明應該足夠詳細使得和模型圖結合
時，它可以提供所有必須的編碼信息。在許多自動化軟件生產過程中，我們可以從面向
對象圖生成代碼框架。圖5和6 說明了對一些領域對象的高層和詳細設計對象。注意樁（
stub）和框架（skeleton）在圖中經常是不可見的，因爲它們對設計人員和編程員來說
是透明的。我將它們包括在圖6中以說明EJB的基礎部分。
圖6 對象設計模型：訂單EJB詳細設計
在完成了詳細對象設計後，還需要完成領域對象的對象-關係映射。原因是雖然面向對象
方法學現在非常流行，但是大多數流行且成熟的持續性存儲卻是關係型的。另外，在許
多情況下，客戶的IT基礎設施已經反映了對商業RDBMS供應商的投資和偏愛。所以，將領
域對象轉換成關係模型或數據庫表是非常重要的。雖然有許多容器管理的持續性工具，
但它們不能取代好的關係數據庫設計。
5、 實現
在良好的架構和詳細設計條件下，實現應該是一個明確的任務。另外，因爲我們設計和
實現架構原型階段的縱向聯合部分，所以實現階段應該更沒有什麼值得驚訝的。在許多
組織中，開發者經常過早地到達實現階段。尤其當管理者盯着開發人員確保在編碼，而
不是做他們認爲在浪費公司時間的其他事情時，這種情況變得更加嚴重。
結果，不再花數小時或數天繪出UML草圖，而是通常在發費數週或數月編碼的同時測試自
己的想法。由於在這種情況下，所有地架構決定和設計都是在編碼階段做出來的，所以
經常過了數月後才發現開發的方向出錯了。
6、 驗證
驗證包括測試驗證系統按設計要求運行並滿足需求。驗證過程發生在整個開發生命週期
的開發和產品環境中。單元測試、集成測試和用戶測試本身就是非常重要的主題。
7、 裝配和部署
構件裝配和解決方案部署在J2EE開發中特別重要。開發和產品環境可能非常不同。如果
EJB在系統中，你需要使用供應商特定的工具得到容器自動生成的類，因爲，正如我以前
指出的，Web和應用程序構件配置對不同的供應商來說是不同的。你也必須考慮要部署的
系統是否含有供應商特定代碼實現。在可擴展架構中，系統結構應該是穩定的但也應該
在不影響整個系統的條件下支持新或老構件的增量部署。
8、 運行和維護
在最後階段，應用程序到了用戶手中，你必須給他們提供培訓和文檔。用戶會發現錯誤
並可能要求新特性。你必須適當地改變管理過程來處理這些情況。你不必爲了部署一個
新構件或取代老構件而關閉一個正在運行的系統。
架構開發過程
知道了必須做出許多架構決定，因此我們必須爲架構開發描繪一個過程。對於一個企業
來說通常有許多應用項目，它們中的一些可能跨越數年，結果是系統演化包含許多週期
。在你的領域裏存在着許多跨越多個項目的通用需求。你應該不費力地在它的生命週期
或其他項目中使用以前項目週期的可擴展且可重用的架構。爲一系列軟件應用提供同屬
結構和行爲的通用框架和可重用軟件架構是非常需要的。
如果是第一個J2EE項目，架構必須做原型、測試、度量、分析並在迭代中進行推敲。藍
圖提供了許多好的設計指導和實踐，寵物店示例程序可以作爲一個很好的參考架構。最
有效地快速、高質量發佈好的解決方案的方法是接受和擴展藍圖參考架構並插入你自己
的業務構件。你最後要做的就是改造車輪。
接受一個參考架構
就我的理解，寵物店架構的精華是模型-視圖-控制和命令模式。你可以將這些模式應用
到以Web爲中心和以EJB爲中心的系統中。對於每個領域對象，視圖用嵌套的JSP表示。控
制器處理相關的業務事件，領域對象封裝業務邏輯、事物和安全。我們使用門戶servle
t作爲中心控制器接受和截獲所有用戶的動作。它將業務事件分發給特定的調用領域對象
改變持續狀態的領域對象控制器。依靠事件處理結果，控制器選擇下一個要展現的視圖
。下面是我們可以修改並在大多數J2EE應用程序中使用的主要構件：
a、 MainServlet：門戶構件，Web容器和框架之間的接口
b、 ModelUpdateListener：獲得模型更新事件對象的接口
c、 ModelUpdateNotifier：當更新模型事件發生時通知偵聽器
d、 RequestProcessor：處理所有從MainServlet來的請求。
e、 RequestHandler：即插即用請求處理構件接口
f、 RequestHandlerMapping：包含請求處理映射規則
g、 RequestToEventTranslator：中心請求處理器根據請求處理映射規則代理即插即用
請求處理構件的請求。將http請求轉換爲業務事件
h、 EstoreEvent：業務事件
i、 ShoppingClientControllerWebImpl：代理EJB層門戶控制器
j、 ScreenflowManager：控制屏幕流，選擇視圖
k、 ModelUpdateManager：EJB層模型更新管理器，通知什麼模型由於事件發生了改變
l、 ShoppingClientControllerEJB：EJB層門戶，爲EJB客戶提供遠程服務
m、 StateMachine：中心事件處理器，根據狀態處理映射規則代理即插即用處理構件的
事件處理
n、 StateHandler：EJB層狀態處理接口
o、 StateHandlerMapping：包含狀態處理映射規則
擴展參考架構
雖然藍圖示例程序是一個好的起點，但應該根據每個項目或領域修改它。設計模式是可
重用的微體系結構，可以使用它擴展參考架構。提供了一組有用的J2EE模式目錄的藍圖
和23個"四人幫"模式都是非常不錯的資源。例如，如果想擴展參考架構支持工作流管理
，你可以在部署或運行時動態地在中心控制器註冊事件處理器。中心控制器會詢問每個
註冊的事件處理器直到一個處理器返回消息表明到了命令鏈的末端。
插入你的業務構件
J2EE技術對每個人都是一樣的，但是不同的領域，我們要解決的問題是不同的。一旦建
立了一個基本的J2EE框架，必須實現一些用例來說明架構確實可以爲你的領域服務。可
以通過選用捕獲系統關鍵功能的場景來實現，這些場景經常使用來展現關鍵的技術風險
。從領域分析模型入手，可以象我們在圖5和6中那樣將領域對象映射成高層和低層設計
模型。實現低層設計模型並測試是否真正在工作。如果每件事都按計劃運行，那麼重新
評估風險開始下一個迭代，擴展要考慮的場景並選擇更多的場景擴展架構的覆蓋範圍。
經過幾次迭代後，原始的架構原型應該變得穩定。識別要購買的構件，要保留的遺留系
統和怎樣將它們對接。下一步是軟件設計，你可以使用設計指導中規定好的類似方法和
過程繼續開發。
一步一步
我們使用一個過程來將一個複雜問題分解爲較小的幾個問題，這使得我們可以更容易的
理解和解決它們。在本文中，我們將J2EE開發分解爲八個步驟，主要集中在架構和設計
。我已經闡述了重要的架構併爲架構決定提供了一個過程。我也討論了J2EE架構師的角
色和可交付產品。
學習使用這些步驟開發J2EE解決方案就象學習跳舞的步驟一樣。首先需要自覺並持之以
恆地練習基本步驟。但是，一旦你對它們相當熟悉後，應該將它們放在一起並將注意力
更多地集中在規模、速度、流和特定上下文中每一步的節奏。但永遠不要讓一個過程限
制了創造性。而應該接受和擴展過程以滿足自己特殊需要。記住，最終目的是提供滿足
客戶需求的完整的J2EE解決方案。