開發J2EE解決方案的八個步驟

當前位置：首頁 → 解決方案 → 信息化平臺（軟件開發）

[聖誕節、元旦優惠活動！]爲感謝各位新老客戶對華寶通的一貫支持與厚愛，凡是12月30日前在本站成功註冊主機將贈送域名一個，做商務型網站送通用網址一個或免費推廣一個月。

開發J2EE解決方案的八個步驟（一）

作者：出處：華寶通更新時間： 2006年11月07日

摘要

Java 2企業版本（The Java 2 Enterprise Edition，J2EE）平臺由4個主要的部分組成：規範，參考實現，兼容性測試包和BluePrints程序。BluePrints描述了一個分佈式組件體系的最佳練習和設計指導方針。這篇文章介紹了一個由八個步驟組成的J2EE開發方法論，該方法是基於Rational Unified Process和BluePrints應用例子的。通過這篇文章，你將可以更好地理解J2EE體系的許多重要主題，並且可以應用這些知識來擴展和修改這個簡單的方法論，從而解決各種特定的商業問題。

在商業領域，我們使用Java 2企業版本（J2EE）來解決商業問題，開發商業的軟件，或者爲其它的商業項目提供聯繫的服務。如果一個公司要使用多層的體系來建立一個電子商務的網站，在其整個開發週期中，通常都需要經理、體系構建人員、設計人員、編程人員、測試人員和數據庫專家參與進來。

爲了讓不同的部分可以有效地工作，我們通常都需要一個軟件開發流程。一個經典的開發流程包括有瀑布模型、快速應用開發（RAD）和最終編程。在這篇文章中，我們將集中介紹一個流行的軟件設計流程--Rational Unified Process（RUP）。RUP提供了一個專門的方法來爲不同的角色分配任務。它的目標是在一個可預計進度和預算內，確保我們生產出高質量的軟件以符合用戶的需要。

我使用RUP作J2EE開發有三個方面的原因。首先，RUP是以體系爲中心的；在提交資源作全方位的開發之前，它首先開發出一個可執行的體系原型。第二，RUP是迭代的而且是基於組件的。該體系的基本通常是包含有一個架構，它可以方便地通過迭代地增加組件，從而在不影響系統其它部分的基礎上，自定義和擴展一個系統的功能。第三。RUP使用一個工業標準的語言--UML，可以將系統的體系和組件以可視化的模型展示。RUP有4個不同的開發階段：初始（inception）, 細化（elaboration）, 構建（construction）和轉換（transition）。這篇文章將從一個技術的觀點來介紹J2EE開發的8個基本步驟，它是維持以體系爲中心的。

1、需求分析

需求分析用來描述系統應該和不應該做什麼，從而開發者和用戶可以創建一個初始化的商業聯繫。你可以用商業的概念、該領域的術語、框圖或者其它方法將功能性的需求寫成文檔，而非功能性的需求，例如性能和事務，可以寫在附加的需求文檔中。你可以用文本或者HTML來創建高級別的UI模型，採取哪種方式，要看你在該項目中介入的深度。

圖一展示了一個典型的電子商務系統。viewOrder圖說明的是一個用戶通過web登錄至系統，查看訂單的列表，並且可點擊進去查看每張訂單的細節。addLineItems說明的是用戶瀏覽產品目錄，選擇感興趣的產品，並且將它們加入到購買訂單中。

II、面向對象的分析

分析產生問題域模型：類、對象和交互。你的分析應該脫離任何的技術或者實現的細節，而應該包含有一個理想的模型。對象分析可幫助你理解問題和獲得問題領域方面的知識。你必須維護一個純領域的模型，它不包含技術的細節，這是由於商業流程的改變要比信息技術慢得多。

上面的兩步--需求分析和麪向對象的分析並不是J2EE特有的，對於許多面向對象的方法論來說，都是很常見的。圖2展示了一個高級別的對象分析模型，它是一個寵物店的例子應用。它說明了我們由需求分析use cases中確定的主要概念。我們將這些概念模型化到對象中，並且確定它們的關係。

　　需求和對象分析的結果是J2EE體系開發的一個入門點。要開發一個體系，你可選擇一個垂直的部分--通常是一個關鍵的部分，例如是訂單領域的對象模型--來作對象設計、實現、測試和開發。（一個垂直的部分，是一個RUP概念，是系統的一小部分。開始點是use case的一個子集，如圖1所示，還有領域分析模型，如圖三所示。一個垂直部分的實現就會產生一個全功能的迷你係統，包括所有層，例如用戶界面層的JavaServer Pages（JSPs），中層的商業對象，例如是Enterprise JavaBeans (EJBs)和後臺的數據庫）。你可以將由原型中得到的經驗應用到域對象中，並且將這些認識作爲對象設計階段的一個設計指導方針。

III、體系規範

經過前面的兩個步驟，商業領域的問題和需求都應該清晰了。現在我們將集中討論技術策略和體系上。一個體系就是各部分一起定義整個系統的藍圖：結構，接口和通信技術。我們可進一步將一個體系劃分爲企業和應用體系。

企業系統體系

企業系統體系覆蓋了硬件和軟件架構，網絡拓撲，開發、測試和生產環境等。這些都反映了一個企業的長線投資。在開發前，你需要評估現有的軟件和硬件架構，如果它不能完全支持J2EE的話，你可能會加入新的組件和升級你現有的系統。你需要徹底地評估硬件，包括有計算機，路由器、交換機和網絡拓撲，因爲它們都會影響系統的性能和穩定，圖4展示了一個多層的網絡拓撲。

圖4中的多層企業體系擁有以下主要的組件：

.Web瀏覽器客戶端，它可能處在客戶端公司的防火牆後面

.HTTP服務器，它通常處在DMZ區

.Web容器主機提供表現或者商業邏輯組件

.應用容器提供商業邏輯組件

.關係數據庫管理系統（RDBMS）和數據庫提供數據和數據邏輯

所使用的系統體系類型是根據你對安全、性能、可靠性的需求以及你公司的財政狀況而定的。要求很低時，你甚至可以使用一臺二手的計算機和一條電話線。在Internet上，有許多開放源代碼的操作系統、Web服務器、應用服務器和數據庫管理系統。這些系統的花費可能只有幾百美金，當然，維護起來可能要麻煩一點。

高端的客戶，例如許多華爾街的財政機構，它們需要的是一個支持安全、高吞吐量和可應付不可預計網絡通信的系統。在這種情況下，你通常就需要一個n層的體系，該體系帶有Web服務器和應用服務器，並且設置爲羣集而達到容錯的目的。

你還需要評估軟件架構，包括Web服務器，安全管理軟件，應用服務器，域名管理服務器，數據庫管理系統和第三方的軟件組件，如果你還沒有購買你的應用服務器，那麼在評估過程中，選擇一個J2EE的生產商將是一個重要的部分。我要提醒你一點，不同廠家對J2EE的實現是有很大不同的，有一些僅支持舊的J2EE版本。此外，一些Web容器或者應用容器可能要比其它的快不少。除了實現J2EE規範外，許多的廠家還售賣J2EE體系的組件或者架構。選擇一個穩定的J2EE廠家也是重要的，因爲這樣可以得到長久的支持。你通常可以購買或者在系統體系級別開發的功能包括有：

。事務處理

。國際化和本地化

。羣集和對象分佈

。Session管理

。應用性能測量和描述

。消息

。工作流管理

。入口和個性化管理

。層到層通信協議

。安全和防火牆

應用體系

應用體系建立在企業系統體系之上，指的是一個特別的項目或者應用。在架構完成後，體系建立人員就會研究如何建立一個專門的應用。如果你的企業體系只是支持一箇舊的J2EE版本，你可能就需要首先升級你的系統。如果由於預算或者時間關係而不能做升級，那麼就必須在舊版本的技術限制下工作。重要的是，要建立企業級的可重用組件。最終的目標是要滿足客戶的需要。

一個體系建立者並不是一個設計者；體系和設計是兩件不同的事情。一個應用體系的範圍是系統的主要結構、它的體系設計模式以及你可以在上面增加組件的架構。體系主要是涉及實現的非功能性方面，而設計是和商業的use cases有關，use cases是指你應用來轉換域對象模型爲一個技術對象模型的部分。應用體系是項目的結構，一個專門的應用。你通常在應用體系結構開發時要作出的決定包括有：

。層間的功能劃分

。模型域對象

。以前的系統需要保存的東西

。購買的軟件組件

。需要建立的組件

。如何集成第三方的組件

圖3中的訂單域對象解釋了你如何做到模型化域對象。對於當前的Java技術，你可以將域對象分佈在幾個地方，包括有作爲開發者管理的持續對象放在Web容器中，作爲EJB放在應用服務器中，或者作爲存儲過程放在RDBMS主機中。

在寵物店的設計圖中，我們將訂單對象設計爲一個實體bean、一個細節的對象和一個數據訪問對象，如圖5和後面的圖6所示。當你看到這些時，你將會認識到其體系的重要性。你可以想一下爲什麼一個在分析模型的域對象被映射爲這麼多對象，以及如果改變該設計的話，將會發生什麼事情。你也許已經聽到過EJB的好處，不過要注意的是不同廠家實現起來的性能是有區別的。當新技術到來時，在將其放在到一個系統之前，你需要做研究並且動手做一些測試。其實所謂體系的開發，就是將設計和實現域對象模型的垂直塊轉換爲設計其它許多域對象。

在J2EE出現的早期，一些面向對象的設計者嘗試將域對象映射到實體bean中，並且將它們在層間傳送。他們擁有非常好的UML框圖，不過得到的結果是一個慢的系統，這是由於不必要的網絡通信造成的。由對象分析直接進入對象設計，而沒有一個體系的設計，沒有清楚地理解一個新技術，這樣通常都會導致一個項目失敗。

可交付的體系

由於J2EE體系是一個相對新的主題，因此一個可交付的J2EE體系並沒有很好地定義。在寵物店的例子應用中，是很難看出體系在哪裏結束和設計在哪裏開始。文檔由高級別的應用體系檢查、Model-View-Controller設計模式的討論和一個體系概覽開始。低級別的文檔就是源代碼。沒有UML框圖。Sun的J2EE企業體系認證的委派部分要求所有的可交付體系都用UML表示。不過，這裏僅表示爲一個類框圖、一個組件框圖和一些對象交互框圖，。這些對於一個真正的J2EE應用來說都是不足夠的。要開始的話，體系規範和流程至少需要以下的方面：

.一份系統體系文檔，用來描述你現有的硬件、軟件、網絡拓撲和其它的組件

.一個應用體系文檔，用來描述應用的主要結構，包括所有對於體系有重要作用的組件、use case組件和以前的組件的一個邏輯視圖

.一個新組件設計指導方針，用來描述所有的設計方針和體系決定，解釋全部這些決定，並且說明如果選擇其它的選項會有什麼可能的結果。這些方針應該包含所有重要的基本決定，以便進行新組件的設計時可遵從這些規定，以維持系統體系的完整性

。一個工作體系原型來評估新的技術；從開發和配置J2EE應用中獲取經驗；建立體系架構；通過測量性能、擴展性來預示所冒的風險；還有向客戶證明你的方法是可行的

在你開發過幾個J2EE方案並且獲得更多的經驗後，原型將不再那麼重要，這時一些UML框圖和一些設計方針就可能已經足夠了。（本文已被瀏覽 100255 次）

發佈人：hbtnet
→ 推薦給我的好友

上篇方案：實現政府大量的服務和管理職能上網
下篇方案：開發J2EE解決方案的八個步驟（二）