本部分設定了隱藏,您已回覆過了,以下是隱藏的內容
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用例則告訴我們用戶瀏覽商品目錄, 選擇自己感興趣的商品, 將它們添加到購物清單中.
IMG upload/forum/20031219171222.jpg[/IMG]
圖1. 購物單用例圖
2 面向對象的分析
分析員產生如下問題域模型: 類, 對象和交互. 你的分析應該獨立於任何技術或實現細節, 包含概念上的模型.對象分析理解問題並獲得問題域的相關知識. 由於業務過程的變化比信息技術慢得多, 你得確保你的域模型不涉及技術細節.
上述兩個步驟—需求分析和麪向對象分析—不是J2EE規範; 它們在許多面向對象方法論中很常見. 圖2更爲詳細地顯示了一個寵物商店應用實例的對象分析模型. 它圖解了我們可以從需求分析用例圖中所能得到的一些主要的概念. 我們將這些概念以對象和他們之間的關係將之模型化.
IMG upload/forum/20031219171447.jpg[/IMG]
Figure 2. 更高層分析模型: 寵物店領域
需求分析和對象分析的結果是J2EE架構開發的切入點. 爲了開發一個架構, 你應當選擇縱向聯合部分—通常是一個主要部分, 例如訂單域對象模型—作爲對象設計, 實現, 測試和部署(vertical piece, 一個RUP概念, 是系統的一部分. 起始點是用例圖的一個子集, 例如圖1所示, 和圖3所示的域分析模型. Vertical piece的實施結果是一個功能齊全的小的系統, 它包括所有層, 例如UI層的JSP, 中間業務層對象如EJB, 還有數據庫). 你可以將原型系統中的經驗應用於域對象, 讓它作爲對象設計階段的設計指導方針.
IMG upload/forum/20031219171646.jpg[/IMG]
Figure 3. 詳細對象分析模型: 購物單
3．架構規格說明
經過了以上兩步, 業務域中的問題和需求應該很清晰了. 現在我們將精力轉向技術策略和架構. 架構是一個總體設計, 它包括系統中一起定義的所有部分: 結構, 接口和通信機制. 我們可以更進一步將架構分爲企業級架構和應用級架構.
企業級系統架構:
企業型架構覆蓋了硬件, 軟件, 網絡技術, 開發, 測試, 產品環境等等. 這是企業的長遠投資. 在開發之前, 你的評估一下現有的軟硬件設施, 如果它們不能很好地支持J2EE可能還得增加一些新的組件或者升級現有的系統. 你得徹底地對調查硬件環境, 包括電腦, 路由器, 交換機和網絡的拓撲結構, 它們都有可能對系統的性能和可靠性帶來影響. 圖4顯示了一個可能存在的多層網絡拓撲結構.
IMG upload/forum/20031219171825.jpg[/IMG]
Figure 4. 企業級架構: 網絡拓撲結構
圖4所示的多層企業級架構有如下主要的組成部分:
* 客戶端的Web瀏覽器, 它有可能位於客戶端所在組織的防火牆的後面
* HTTP服務器是面向公衆的服務器端. 它通常位於子網之中
* Web容器, 包含表示層, 可能還有業務邏輯組件.
* 應用服務器, 包含業務邏輯組件.
* 關係數據庫管理系統(RDBMS)和數據庫, 包含數據和數據邏輯.
你所用的系統架構取決於你對於安全, 性能, 可靠性的要求, 當然還得考慮組織的經濟狀況. 對於最低端的應用, 你可以合理地在倉庫裏使用二手電腦, 用電話線連接. 網上有許多開源的操作系統, Web服務器, 應用服務器, 數據庫管理系統可用. 那麼這個系統你可能只需要付出幾百美元和熬幾個通宵而已.
對於高端客戶, 例如華爾街上的金融機構, 可能要求系統能持續地支持安全, 高吞吐量的事務處理, 和不可預知的網絡流量. 在這種情況下, 通常你需要由包含Web服務器和應用服務器的n層架構來配置成集羣以提高容錯性.
同樣你也得考慮軟件組織, 包括Web服務器, 安全管理軟件, 應用服務器, 域名管理服務器, 數據庫管理系統, 和第三方軟件組件. 如果你還沒有購買應用服務器, 選擇一個J2EE提供商是整個評估過程中的一個重要方面. 不同的提供商對於J2EE的實施區別很大, 有些提供商僅僅支持J2EE的舊版本. 另外, 有些Web容器和應用容器可能比較超前. 與J2EE規範的實施不同的是, 許多提供商可能也同時賣J2EE組件或框架. 選擇一個提供支持的穩定的J2EE供應商也很關鍵. 你能購買或開發的系統級常用功能包括:
事務
網絡化和本地化
集羣和對象分佈
會話管理
應用性能的衡量和profilling
消息
工作流管理
入口和個性化管理
層與層之間的通信協議
安全和防火牆
應用級架構
構建於企業級系統架構之上的應用架構與特定的項目或應用有關. 基礎組織完成後, 架構師就得考慮特定的應用了. 如果你的企業架構只是部分支持J2EE的舊版本, 你可能得首先升級你的系統. 如果你基於預算或時間的考慮不能升級你的系統, 你就得考慮清楚由於使用舊版本帶來的一些限制. 構建可複用的企業級組建也很重要, 在考慮它的可用性之前你就得考慮其可複用性. 最終的目標是滿足客戶的需求—在某個時間完成項目.
架構師不是設計師; 架構和設計是兩個不同的概念. 應用架構的範圍包括系統的主要結構, 架構設計模式和框架, 依賴於這些你可以添加組件. 架構所關注的是非功能性的, 而設計關注的是你將域對象模型轉換爲技術上的對象模型所用到的邏輯用例. 應用架構是項目結構, 特殊的應用. 應用架構開發過程中通常需考慮的部分包括:
層之間的功能
模型域對象
可繼承的系統保存什麼(What legacy system to save)
購買什麼樣的軟件組件
購買什麼組件
如何集成第三方組件
圖3所示購物單域對象示範瞭如何對域對象建模. 如今的Java技術允許你進行分佈式開發, 域對象作爲開發者管理的持久化對象位於Web容器, 應用服務器包含EJB, 關係數據庫管理系統存儲數據.
在寵物商店BluePrint中, 我們將訂單對象設計爲一個實體Bean, 一個詳細的對象, 一個數據訪問對象, 如圖5和其後的圖6所示. 當你看到這些的時候, 你可能就明白了架構的重要性. 試問一下在模型分析中一個域對象映射到那麼多對象, 如果你改變了設計會發生什麼. 你可能聽說了一些EJB的優點, 也明白不同提供商的實現的性能也是大不相同. 一項新技術出現後, 在利用其進行大規模設計之前你需要進行研究並做一些輔助性的工作. 你可以將在設計和實現域對象模型的vertical pieces中學到的知識應用於許多其它的域對象的設計之中. 這就是架構開發相關內容.
IMG upload/forum/20031219172007.jpg[/IMG]
Figure 5. 購物單對項涉及模型
在J2EE的早期, 有些面向對象設計師試圖將域對象映射爲實體Bean並通過層傳遞它們. 他們設計出不錯的UML圖, 但結果由於不必要的網絡流量導致系統速度非常慢.
如果在對象分析後不進行架構開發, 缺乏對新技術的完全理解就直接進入對象設計，幾乎總是會導致項目的失敗.
架構交付
由於J2EE架構是一個相對較新的課題, J2EE架構的交付不太好定義. 以寵物商店的應用爲例, 很難明確什麼時候架構開發結束, 設計開始. 文檔開始於對應用架構所作的高級別的檢查, 對MVC設計模式的討論和對架構的總體理解. 低層次的文檔適用於源程序. Sun的J2EE企業架構設計證明要求UML圖中包括所有可交付部分. 然而這些符號只存在於類圖, 組件圖, 和一些對象交互圖中. 這在現實世界中的J2EE應用中遠遠不夠. 爲了開始, 架構規範和過程至少需要下面的部分:
* 系統架構系統, 描述已有的硬件, 軟件, 網絡技術和其他組件
* 應用架構文檔, 描述應用的主要結構, 包括所有架構中所有重要組件的邏輯試圖, 用例, 可複用的組件
* 新組件的設計指導方針, 描述所有涉及指導方針, 架構定義, 解釋所有定義, 描述如果應用替代品時應採
用的時序. 這些指導方針應當包括所有重要的, 基本的, 決定性的部分, 使得新的組件設計不會影響現有
系統的架構完整性.
* 一個用於評估新技術的可運行的架構原型; 在開發和部署J2EE應用中獲得經驗; 創建架構的框架; 通過
權衡性能, 可測量性, 難易度來評估風險; 向項目客戶提供方案可行性報告.
在解決了一些J2EE問題, 獲得了更多的經驗後, 原型就變得不是很重要了, 一些UML圖和一些設計指導方針就足夠了.
4. 對象設計
設計技術以架構規範作指導, 是分析結果的擴充和進一步體現. 分析階段的域對象模型與技術細節無關, 而對象設計則與技術要素有着密切的關係, 包括平臺類型, 語言, 架構開發階段所選擇的提供商. 分析階段可能只關注目標, 但設計階段就得腳踏實地了. 除非必須保持基本屬性和行爲, 否則不要輕易讓你的設計受到業務對象的影響.
以架構設計爲指導, 詳細設計應考慮到所有類的式樣, 包括實現細節, 詳細的接口, 操作的僞代碼或者解釋的文字性描述. 說明書要足夠詳細, 包括模型圖, 它提供所有必要的編碼信息. 有些開發工具有自動生成的功能, 你可以根據面向對象圖表生成代碼骨架. 圖5和圖6分別在較高層次和詳細的對象設計層次上圖示了一些域模型. 注意由於存根和骨架對於設計師和程序員是透明的因而它們通常不出現在圖表中. 我將它們包含在圖6中用於闡述EJB基本概念.
IMG upload/forum/20031219172210.jpg[/IMG]
Figure 6. 對項涉及模型: 訂單EJB詳細設計
在詳細的對象設計完成後, 你也就完成了域對象的對象關係映射. 這麼做的理由是儘管面向對象方法論現在比較先進, 但最流行, 最成熟的持久化存儲還是關係型的. 另外在許多案例中客戶先期所用的是關係數據庫管理系統, 最好能保留他們的已有投資. 所以將於對象模型轉換爲關係模型或數據表是很重要的. 有許多容器管理的持久化工具, 但它們還是不能替代好的關係數據庫設計.
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框架，必須實現一些用例來說明架構確實可以爲你的領域服務。可以通過選用捕獲系統關鍵功能的場景來實現，這些場景經常使用來展現關鍵的技術風險。從領域分析模型入手，可以象我們在圖5和6中那樣將領域對象映射成高層和低層設計模型。實現低層設計模型並測試是否真正在工作。如果每件事都按計劃運行，那麼重新評估風險開始下一個迭代，擴展要考慮的場景並選擇更多的場景擴展架構的覆蓋範圍。經過幾次迭代後，原始的架構原型應該變得穩定。識別要購買的構件，要保留的遺留系統和怎樣將它們對接。下一步是軟件設計，你可以使用設計指導中規定好的類似方法和過程繼續開發。
一步一步
我們使用一個過程來將一個複雜問題分解爲較小的幾個問題，這使得我們可以更容易的理解和解決它們。在本文中，我們將J2EE開發分解爲八個步驟，主要集中在架構和設計。我已經闡述了重要的架構併爲架構決定提供了一個過程。我也討論了J2EE架構師的角色和可交付產品。
學習使用這些步驟開發J2EE解決方案就象學習跳舞的步驟一樣。首先需要自覺並持之以恆地練習基本步驟。但是，一旦你對它們相當熟悉後，應該將它們放在一起並將注意力更多地集中在規模、速度、流和特定上下文中每一步的節奏。但永遠不要讓一個過程限制了創造性。而應該接受和擴展過程以滿足自己特殊需要。記住，最終目的是提供滿足客戶需求的完整的J2EE解決方案。