J2EE系統架構和過程淺析
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模型。
在一個典型電子商務系統中的兩個用例。查看訂單（viewOrder）用例告訴我們一個用戶通過Web界面登陸系統、查看訂單列表，點擊鏈接查看特定訂單的詳細信息。增加訂單項（addLineItem）用例告訴我們瀏覽產品列表、選擇感興趣的產品并將它們添加到購買訂單中。
2、面向對象分析人員構造問題領域模型：類、對象和交互。分析應該與技術和實現細節無關，并包含一個理想的模型。對象分析可以幫助理解問題并獲得關于問題領域的知識。因為業務過程的改變比信息技術的改變要慢得多，所以必須要維持一個不含技術細節的純領域模型。這兩個步驟--需求分析和面向對象分析--不是J2EE特有的；對許多面向對象方法學來說，它們都非常通用。
一個寵物店示例程序的高層對象分析模型。它用圖例說明了我們從需求分析用例中識別的主要概念。我們把這些概念建模成對象并標識它們的關系。為了開發架構，可以選擇一個縱向聯合部分（verticalpiece）--經常是關鍵部分，如訂單領域對象模型--進行對象設計、實現、測試和部署。（縱向聯合部分，一個RUP概念，是指系統的一小部分。起始點是圖1所示的用例子集和圖3所示的領域分析模型。一個縱向聯合部分的實現結果是一個全功能的微小系統，包括UI層的JSP，中間層業務對象如EJB和后端數據庫。）可以將從原型中獲得的經驗應用于領域對象并作為對象設計階段的指導。
3、架構規格說明經過前面兩個步驟，業務領域問題和需求應該比較明確了。現在，我們將工作集中在技術策略和架構上。架構是指所有構件組合定義系統的一個藍圖：結構、接口和通訊機制。我們可以進一步將架構分為企業級和應用級架構。企業級系統架構企業級系統架構包括硬件和軟件基礎設施、網絡布局、開發、測試、生產環境等等。它反映了一個企業的長期投資。開發前，需要評估已存在的軟件和硬件基礎設施，如果不完全支持J2EE的話，增加新構件更新已存在系統。你需要徹底地評估硬件，包括計算機、路由器、網絡轉換器和網絡布局，因為它們都影響到系統的性能和可靠性。
4企業級架構：一個多層企業級架構包括以下幾個主要構件：一個Web瀏覽器客戶端，可能在也可能不在客戶端組織的防火墻內一個HTTP服務器，是一個對公眾開放的Web服務器。它通常位于一個稱作DMZ的子網內Web容器主表示層和可能的業務邏輯構件應用程序容器主業務邏輯構件關系數據庫管理系統（RDBMS）和數據庫主數據、數據邏輯你使用的系統架構類型依賴于安全、性能和可靠性的需求，也依賴于組織的財政狀況。在缺少經驗的情況下，也可以適當地從一個修理廠電話訂購一臺簡單地二手計算機。
Internet上有許多開放源代碼的操作系統、Web服務器、應用程序服務器和數據庫管理系統。得到這些系統的代價只是幾百美元和熬幾個通宵。象許多華爾街金融機構這樣的高端客戶也許需要一個連續支持安全、高吞吐量交易和不可預料網絡通訊的系統。在這種情況下，為了容錯，通常需要將Web服務器和應用程序服務器集群配置成一個n層架構。還需要評估軟件基礎設施，包括Web服務器、安全管理軟件、應用程序服務器、域名管理服務器、數據庫管理系統和第三方軟件構件。如果還沒有購買應用程序服務器，選擇一個J2EE供應商將是評估過程的一個重要方面。應該注意到不同的供應商對J2EE的實現程度是不同的，一些供應商只支持老的J2EE版本。
另外，一些Web容器或應用程序容器可能比其他的速度要快。除了實現J2EE規范外，許多供應商還出售J2EE基礎構件或框架。選擇一個穩定的提供支持的J2EE供應商也非常關鍵。你可以在系統基礎設施層面上購買或開發的通用功能包括：事務國際化和本地化集群和對象分布應用程序性能度量和剖析通訊工作流管理入口和個性化管理層對層通訊協議安全和防火墻應用架構應用架構參考一個特定的項目和規范建立在企業級系統架構的上層。在基礎設施完成后，架構師研究怎樣構造一個特定的應用。如果你的企業級架構僅部分支持老的J2EE版本，可以先升級你的系統。如果由于預算或時間關系不能升級，那么必須在更老版本規定的技術范圍內開展工作。雖然構造企業級重用構件非常重要，但是必須首先要能夠使用。這里的最終目標是滿足客戶的需求--一次一個項目。
架構師不是設計師；架構和設計是完全不同。一個應用架構的范圍包括系統的主要結構、架構設計模式和可以在上面增加構件的框架。架構主要關注的是非功能性方面，而設計關注應用業務用例將領域對象模型轉換成技術對象模型。應用架構是項目的結構，一個特殊的應用程序。通過應用架構開發，你通常必須要做的應用架構決定包括：層之間進行功能劃分領域對象建模要保護的遺留系統要購買的軟件構件要開發的構件怎樣集成第三方構件圖3的訂單領域對象說明了怎樣對領域對象進行建模。利用當前的Java技術，可以將領域對象分布在作為開發者管理持續性對象的Web容器中、應用程序服務器的EJB中或者作為RDBMS宿主的Java存儲過程中。在寵物店藍圖中，我們將訂單對象設計成一個實體bean，一個詳細對象和一個數據訪問對象，如圖5和后面的圖6所示。當你看到這個的時候，你應該意識到架構的重要性。為什么分析模型中的一個領域對象映射成這么多對象？如果改變設計，會出現什么問題？你也許聽說過EJB的好處，但是要注意不同供應商的性能是不同的。當一種新技術到來的時候，你需要在投入全面設計之前進行一些研究。你可以經常地將設計和實現領域對象模型縱向聯合部分的經驗應用到其他許多領域對象中。這就是架構開發的內容。
對象設計在架構規范的指導下，設計從技術上擴展和修改了分析結果。雖然分析階段的領域對象建模應該與技術細節無關，但是對象設計完全依賴于技術因素，包括平臺、語言的類型和架構開發階段選擇的供應商。分析時，抬頭望著星星，但在設計階段，則要腳踏實地。理論上，為了維持業務對象的基本屬性和行為，除非絕對必要，不應該破壞它們。在架構結果的指導下，詳細設計工作應該說明所有類的規格，包括必須實現的屬性、它們的詳細接口和偽代碼或操作的純文本描述。規格說明應該足夠詳細使得和模型圖結合時，它可以提供所有必須的編碼信息。在許多自動化軟件生產過程中，我們可以從面向對象圖生成代碼框架。注意樁（stub）和框架（skeleton）在圖中經常是不可見的，因為它們對設計人員和編程員來說是透明的。
#p#對象設計模型：訂單EJB詳細設計在完成了詳細對象設計后，還需要完成領域對象的對象-關系映射。原因是雖然面向對象方法學現在非常流行，但是大多數流行且成熟的持續性存儲卻是關系型的。另外，在許多情況下，客戶的IT基礎設施已經反映了對商業RDBMS供應商的投資和偏愛。所以，將領域對象轉換成關系模型或數據庫表是非常重要的。雖然有許多容器管理的持續性工具，但它們不能取代好的關系數據庫設計。
5、實現在良好的架構和詳細設計條件下，實現應該是一個明確的任務。另外，因為我們設計和實現架構原型階段的縱向聯合部分，所以實現階段應該更沒有什么值得驚訝的。在許多組織中，開發者經常過早地到達實現階段。尤其當管理者盯著開發人員確保在編碼，而不是做他們認為在浪費公司時間的其他事情時，這種情況變得更加嚴重。結果，不再花數小時或數天繪出UML草圖，而是通常在發費數周或數月編碼的同時測試自己的想法。由于在這種情況下，所有地架構決定和設計都是在編碼階段做出來的，所以經常過了數月后才發現開發的方向出錯了。
6、驗證驗證包括測試驗證系統按設計要求運行并滿足需求。驗證過程發生在整個開發生命周期的開發和產品環境中。單元測試、集成測試和用戶測試本身就是非常重要的主題。
7、裝配和部署構件裝配和解決方案部署在J2EE開發中特別重要。開發和產品環境可能非常不同。如果EJB在系統中，你需要使用供應商特定的工具得到容器自動生成的類，因為，正如我以前指出的，Web和應用程序構件配置對不同的供應商來說是不同的。你也必須考慮要部署的系統是否含有供應商特定代碼實現。在可擴展架構中，系統結構應該是穩定的但也應該在不影響整個系統的條件下支持新或老構件的增量部署。
8、運行和維護在最后階段，應用程序到了用戶手中，你必須給他們提供培訓和文檔。用戶會發現錯誤并可能要求新特性。你必須適當地改變管理過程來處理這些情況。你不必為了部署一個新構件或取代老構件而關閉一個正在運行的系統。架構開發過程知道了必須做出許多架構決定，因此我們必須為架構開發描繪一個過程。對于一個企業來說通常有許多應用項目，它們中的一些可能跨越數年，結果是系統演化包含許多周期。在你的領域里存在著許多跨越多個項目的通用需求。你應該不費力地在它的生命周期或其他項目中使用以前項目周期的可擴展且可重用的架構。為一系列軟件應用提供同屬結構和行為的通用框架和可重用軟件架構是非常需要的。
如果是第一個J2EE項目，架構必須做原型、測試、度量、分析并在迭代中進行推敲。藍圖提供了許多好的設計指導和實踐，寵物店示例程序可以作為一個很好的參考架構。最有效地快速、高質量發布好的解決方案的方法是接受和擴展藍圖參考架構并插入你自己的業務構件。你最后要做的就是改造車輪。接受一個參考架構就我的理解，寵物店架構的精華是模型-視圖-控制和命令模式。你可以將這些模式應用到以Web為中心和以EJB為中心的系統中。對于每個領域對象，視圖用嵌套的JSP表示。控制器處理相關的業務事件，領域對象封裝業務邏輯、事物和安全。我們使用門戶servlet作為中心控制器接受和截獲所有用戶的動作。它將業務事件分發給特定的調用領域對象改變持續狀態的領域對象控制器。依靠事件處理結果，控制器選擇下一個要展現的視圖。
下面是我們可以修改并在大多數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框架，必須實現一些用例來說明架構確實可以為你的領域服務。可以通過選用捕獲系統關鍵功能的場景來實現，這些場景經常使用來展現關鍵的技術風險。
從領域分析模型入手，可以將領域對象映射成高層和低層設計模型。實現低層設計模型并測試是否真正在工作。如果每件事都按計劃運行，那么重新評估風險開始下一個迭代，擴展要考慮的場景并選擇更多的場景擴展架構的覆蓋范圍。經過幾次迭代后，原始的架構原型應該變得穩定。識別要購買的構件，要保留的遺留系統和怎樣將它們對接。
下一步是軟件設計，你可以使用設計指導中規定好的類似方法和過程繼續開發。一步一步我們使用一個過程來將一個復雜問題分解為較小的幾個問題，這使得我們可以更容易的理解和解決它們。在本文中，我們將J2EE開發分解為八個步驟，主要集中在架構和設計。我已經闡述了重要的架構并為架構決定提供了一個過程。我也討論了J2EE架構師的角色和可交付產品。學習使用這些步驟開發J2EE解決方案就象學習跳舞的步驟一樣。首先需要自覺并持之以恒地練習基本步驟。但是，一旦你對它們相當熟悉后，應該將它們放在一起并將注意力更多地集中在規模、速度、流和特定上下文中每一步的節奏。但永遠不要讓一個過程限制了創造性。而應該接受和擴展過程以滿足自己特殊需要。記住，最終目的是提供滿足客戶需求的完整的J2EE解決方案。
【編輯推薦】
