步入J2EE架構和過程(1)
來源:IT網絡學院 2003年5月10日0:21
摘要
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)和資料庫主資料、資料邏輯
你使用的系統架構類型依賴于安全、性能和可靠性的需求,也依賴于組織的财政狀況。在
缺少經驗的情況下,也可以适當地從一個修理廠電話訂購一台簡單地二手計算機。
Internet上有許多開放源代碼的作業系統、Web伺服器、應用程式伺服器和資料庫管理系
統。得到這些系統的代價隻是幾百美元和熬幾個通宵。
象許多華爾街金融機構這樣的高端客戶也許需要一個連續支援安全、高吞吐量交易和不可
預料網絡通訊的系統。在這種情況下,為了容錯,通常需要将Web伺服器和應用程式服務
器叢集配置成一個n層架構。
還需要評估軟體基礎設施,包括Web伺服器、安全管理軟體、應用程式伺服器、域名管理
伺服器、資料庫管理系統和第三方軟體構件。如果還沒有購買應用程式伺服器,選擇一個
J2EE供應商将是評估過程的一個重要方面。應該注意到不同的供應商對J2EE的實作程度是
不同的,一些供應商隻支援老的J2EE版本。另外,一些Web容器或應用程式容器可能比其
他的速度要快。除了實作J2EE規範外,許多供應商還出售J2EE基礎構件或架構。選擇一個
穩定的提供支援的 J2EE供應商也非常關鍵。你可以在系統基礎設施層面上購買或開發的
通用功能包括:
事務
國際化和本地化
叢集和對象分布
應用程式性能度量和剖析
通訊
工作流管理
入口和個性化管理
層對層通訊協定
安全和防火牆
應用架構
應用架構參考一個特定的項目和規範建立在企業級系統架構的上層。在基礎設施完成後,
架構師研究怎樣構造一個特定的應用。如果你的企業級架構僅部分支援老的 J2EE版本,
可以先更新你的系統。如果由于預算或時間關系不能更新,那麼必須在更老版本規定的技
術範圍内開展工作。雖然構造企業級重用構件非常重要,但是必須首先要能夠使用。這裡
的最終目标是滿足客戶的需求--一次一個項目。
架構師不是設計師;架構和設計是完全不同。一個應用架構的範圍包括系統的主要結構、
架構設計模式和可以在上面增加構件的架構。架構主要關注的是非功能性方面,而設計關
注應用業務用例将領域對象模型轉換成技術對象模型。應用架構是項目的結構,一個特殊
的應用程式。通過應用架構開發,你通常必須要做的應用架構決定包括:
層之間進行功能劃分
領域對象模組化
要保護的遺留系統
要購買的軟體構件
要開發的構件
怎樣內建第三方構件
圖3的訂單領域對象說明了怎樣對領域對象進行模組化。利用目前的Java技術,可以将領域
對象分布在作為開發者管理持續性對象的Web容器中、應用程式伺服器的EJB中或者作為
RDBMS宿主的Java存儲過程中。
在寵物店藍圖中,我們将訂單對象設計成一個實體bean,一個詳細對象和一個資料通路對
象,如圖5和後面的圖6所示。當你看到這個的時候,你應該意識到架構的重要性。為什麼
分析模型中的一個領域對象映射成這麼多對象?如果改變設計,會出現什麼問題?你也許
聽說過EJB的好處,但是要注意不同供應商的性能是不同的。當一種新技術到來的時候,
你需要在投入全面設計之前進行一些研究。你可以經常地将設計和實作領域對象模型縱向
聯合部分的經驗應用到其他許多領域對象中。這就是架構開發的内容。
按此在新視窗浏覽圖檔
圖4 企業級架構:網絡布局
如圖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的好處,但是要注意不同供應商的性能是不同的。當一種新技術到來的時候,
你需要在投入全面設計之前進行一些研究。你可以經常地将設計和實作領域對象模型縱向
聯合部分的經驗應用到其他許多領域對象中。這就是架構開發的内容。