J2EE平台由四個關鍵的部分定義: 規范, 實現參考, 兼容性測試例和藍圖計劃(BluePrint). 藍圖描述分布式組件架構的最佳實踐和設計指導方針. 本文介紹了基於Rational統一開發過程(Rational Unified Process)和設計圖應用實例的八個步驟的J2EE開發. 通過閱讀本文，你將更好地懂得許多重要的J2EE架構方面的主題，並能夠將這些知識應用於擴展和修改這個簡單的實例以解決你特定的邏輯問題(September 28, 2001)
在商業世界裡, 我們使用J2EE解決商業問題來開發商業軟件或給別的商業項目提供約定服務. 如果一個公司想利用多層架構開發一個電子商務站點，整個開發生命周期通常包括管理員, 架構師, 設計師, 程序員, 測試者, 和數據庫專家.
為了使各個不同的部分能更有效的協同工作, 他們通常需要遵循一定的軟件開發流程. 經典的開發流程包括瀑布模型, 快速原型開發(RAD)和極限編程(XP). 在本文中我們將聚焦於統一開發過程(RUP). RUP提供一種經過檢驗的方法來分配任務和責任給不同的角色. 其目標是保證我們生產出可預期, 可預算, 符合我們需求的高質量的軟件.
我之所以喜歡在J2EE的開發過程中使用RUP出於以下三個原因: 首先, RUP是以架構為中心的; 它在為大規模開發提交資源之前開發出一個可執行的架構原型. 其次, RUP是基於迭代並基於架構的. 其架構通常包括框架和基礎結構, 可以反復地加入新的組件來定制的擴充系統的功能, 而這些都不會影響到系統的其它部分. 最後RUP使用行業標准語言—UML來為系統架構和組件建模. RUP有四個不同的開發階段: 初始階段, 細化階段, 構造階段, 和交付階段. 本文從技術的觀點出發, 著重強調架構
的思想, 涵蓋了J2EE開發所涉及到的八個基本的步驟.
1. 需求分析
需求分析描述了系統應該做什麼, 不應該做什麼, 在此基礎上開發者和客戶可以達成共識. 你可以將功能性的需求如業務概念, 領域術語, 用例和用戶界面(UI)形成文檔. 非功能性的需求, 例如性能, 事務等可以在輔助性的需求文檔中指出. 你可以在紙上或者以HTML的形式創建高水准的用戶界面, 這取決於你參與項目的深度.
圖1表示一個典型的電子商務系統中的兩個示例性的用例圖. viewOrder用例告訴我們用戶通過Web界面登錄系統, 查看訂單列表, 點擊一個鏈接查看購物訂單的詳細內容. addLineItems用例則告訴我們用戶浏覽商品目錄, 選擇自己感興趣的商品, 將它們添加到購物清單中.
圖1. 購物單用例圖
2 面向對象的分析
分析員產生如下問題域模型: 類, 對象和交互. 你的分析應該獨立於任何技術或實現細節, 包含概念上的模型.對象分析理解問題並獲得問題域的相關知識. 由於業務過程的變化比信息技術慢得多, 你得確保你的域模型不涉及技術細節.
上述兩個步驟—需求分析和面向對象分析—不是J2EE規范; 它們在許多面向對象方法論中很常見. 圖2更為詳細地顯示了一個寵物商店應用實例的對象分析模型. 它圖解了我們可以從需求分析用例圖中所能得到的一些主要的概念. 我們將這些概念以對象和他們之間的關系將之模型化.
Figure 2. 更高層分析模型: 寵物店領域
需求分析和對象分析的結果是J2EE架構開發的切入點. 為了開發一個架構, 你應當選擇縱向聯合部分—通常是一個主要部分, 例如訂單域對象模型—作為對象設計, 實現, 測試和部署(vertical piece, 一個RUP概念, 是系統的一部分. 起始點是用例圖的一個子集, 例如圖1所示, 和圖3所示的域分析模型. Vertical piece的實施結果是一個功能齊全的小的系統, 它包括所有層, 例如UI層的JSP, 中間業務層對象如EJB, 還有數據庫). 你可以將原型系統中的經驗應用於域對象, 讓它作為對象設計階段的設計指導方針.
Figure 3. 詳細對象分析模型: 購物單
3．架構規格說明
經過了以上兩步, 業務域中的問題和需求應該很清晰了. 現在我們將精力轉向技術策略和架構. 架構是一個總體設計, 它包括系統中一起定義的所有部分: 結構, 接口和通信機制. 我們可以更進一步將架構分為企業級架構和應用級架構.
企業級系統架構:
企業型架構覆蓋了硬件, 軟件, 網絡技術, 開發, 測試, 產品環境等等. 這是企業的長遠投資. 在開發之前, 你的評估一下現有的軟硬件設施, 如果它們不能很好地支持J2EE可能還得增加一些新的組件或者升級現有的系統. 你得徹底地對調查硬件環境, 包括電腦, 路由器, 交換機和網絡的拓撲結構, 它們都有可能對系統的性能和可靠性帶來影響. 圖4顯示了一個可能存在的多層網絡拓撲結構.
Figure 4. 企業級架構: 網絡拓撲結構
圖4所示的多層企業級架構有如下主要的組成部分:
? * 客戶端的Web浏覽器, 它有可能位於客戶端所在組織的防火牆的後面
? * HTTP服務器是面向公眾的服務器端. 它通常位於子網之中
? * Web容器, 包含表示層, 可能還有業務邏輯組件.
? * 應用服務器, 包含業務邏輯組件.
? * 關系數據庫管理系統(RDBMS)和數據庫, 包含數據和數據邏輯.
你所用的系統架構取決於你對於安全, 性能, 可靠性的要求, 當然還得考慮組織的經濟狀況. 對於最低端的應用, 你可以合理地在倉庫裡使用二手電腦, 用電話線連接. 網上有許多開源的操作系統, Web服務器, 應用服務器, 數據庫管理系統可用. 那麼這個系統你可能只需要付出幾百美元和熬幾個通宵而已.
對於高端客戶, 例如華爾街上的金融機構, 可能要求系統能持續地支持安全, 高吞吐量的事務處理, 和不可預知的網絡流量. 在這種情況下, 通常你需要由包含Web服務器和應用服務器的n層架構來配置成集群以提高容錯性.
同樣你也得考慮軟件組織, 包括Web服務器, 安全管理軟件, 應用服務器, 域名管理服務器, 數據庫管理系統, 和第三方軟件組件. 如果你還沒有購買應用服務器, 選擇一個J2EE提供商是整個評估過程中的一個重要方面. 不同的提供商對於J2EE的實施區別很大, 有些提供商僅僅支持J2EE的舊版本. 另外, 有些Web容器和應用容器可能比較超前. 與J2EE規范的實施不同的是, 許多提供商可能也同時賣J2EE組件或框架. 選擇一個提供支持的穩定的J2EE供應商也很關鍵. 你能購買或開發的系統級常用功能包括:
? 事務
? 網絡化和本地化
? 集群和對象分布
? 會話管理
? 應用性能的衡量和profilling
? 消息
? 工作流管理
? 入口和個性化管理
? 層與層之間的通信協議
? 安全和防火牆
