當前流行的J2EE WEB應用架構分析

1. 架構概述

J2EE體系包括java server pages(JSP) ,java SERVLET, enterprise bean，WEB service等技術。這些技術的出現給電子商務時代的WEB應用程序的開發提供了一個很是有競爭力的選擇。怎樣把這些技術組合起來造成一個適應項目須要的穩定架構是項目開發過程當中一個很是重要的步驟。完成這個步驟能夠造成一個主要里程碑基線。造成這個基線有不少好處：

各類因數初步肯定

爲了造成架構基線，架構設計師要對平臺（體系）中的技術進行篩選，各類利弊的權衡。每每架構設計師在這個過程當中要閱讀大量的技術資料，聽取項目組成員的建議，考慮領域專家的需求，考慮贊助商成本（包括開發成本和運行維護成本）限額。一旦架構設計通過評審，這些因數初步地就有了在整個項目過程當中的對項目起多大做用的定位。

定向技術培訓

一旦架構師設計的架構獲得了批准造成了基線，項目開發和運行所採用的技術基本肯定下來了。衆多的項目經理都會對預備項目組成員的技術功底感到擔憂；他們須要培訓部門提供培訓，但就架構師面對的技術海洋，項目經理根本就提不出明確的技術培訓需求。怎不可以對體系中全部技術都進行培訓吧！有了架構里程碑基線，項目經理能肯定這個項目開發會採用什麼技術，這是提出培訓需求應該是最精確的。不過在實際項目開發中，技術培訓能夠在基線肯定以前與架構設計併發進行。

角色分工

有了一個好的架構藍圖，咱們就能準確劃分工做。如網頁設計，JSP 標籤處理類設計，SERVLET 設計，session bean設計，還有各類實現。這些任務在架構藍圖上均可以清晰地標出位置，使得項目組成員能很好地定位本身的任務。一個好的架構藍圖同時也能規範化任務，能很好地把任務劃分爲幾類，在同一類中的任務的工做量和性質相同或類似。這樣工做量估計起來有一個很是好的基礎。

運行維護

前面說過各個任務在架構圖上都有比較好的定位。任何人能借助它很快地熟悉整個項目的運行狀況，錯誤出現時能比較快速地定位錯誤點。另外，有了清晰的架構圖，項目版本管理也有很好的版本樹軀幹。

擴展性

架構猶如一顆參天大樹的軀幹，只要軀幹根系牢，樹幹粗，長一些旁支，加一些樹葉垂手可得無疑。一樣，有一個穩定的經得起考驗的架構，增長一兩個業務組件是很是快速和容易的。

你們都知道這些好處，一心想造成一個這樣的J2EE應用程序架構（就像在windows平臺中的MFC）。在這個路程中經歷了兩個大的階段：

1.1. 模型1

模型1其實不是一個什麼穩定架構，甚至談不上造成了架構。模型1的基礎是JSP文件。它從HTTP的請求中提取參數，調用相應的業務邏輯，處理HTTP會話，最後生成HTTP文檔。一系列這樣的JSP文件造成一個完整的模型1應用，固然可能會有其餘輔助類或文件。早期的ASP 和 PHP 技術就屬於這個狀況。

總的看來，這個模型的好處是簡單，可是它把業務邏輯和表現混在一塊，對大應用來講，這個缺點是使人容忍不了的。

1.2. 模型2

在通過一番實踐，並普遍借鑑和總結經驗教訓以後，J2EE應用程序終於迎來了MVC（模型-視圖-控制）模式。MVC模式並非J2EE行業人士標新立異的，因此前面我談到廣發借鑑。MVC的核心就是作到三層甚至多層的鬆散耦合。這對基於組件的，所覆蓋的技術不斷膨脹的J2EE體系來講真是福音和救星。

它在瀏覽器（本文對客戶代理都稱瀏覽器）和JSP或SERVLET之間插入一個控制組件。這個控制組件集中了處理瀏覽器發過來的HTTP請求的分發邏輯，也就是說，它會根據HTTP請求的URL,輸入參數，和目前應用的內部狀態，把請求分發給相應的WEB 層的JSP 或SERVLET。另外它也負責選擇下一個視圖（在J2EE中，JSP,SERVLET會生成回給瀏覽器的html從而造成視圖）。集中的控制組件也有利於安全驗證，日誌紀錄，有時也封裝請求數據給下面的WEB tier層。這一套邏輯的實現造成了一個像MFC的應用框架，位置如圖：

 

1.3. 多層應用

下圖爲J2EE體系中典型的多層應用模型。

Client tier客戶層

通常爲瀏覽器或其餘應用。客戶層廣泛地支持HTTP協議，也稱客戶代理。

WEB tier WEB應用層

在J2EE中，這一層由WEB 容器運行，它包括JSP, SERVLET等WEB部件。

EJB tier 企業組件層

企業組件層由EJB容器運行，支持EJB, JMS, JTA 等服務和技術。

EIS tier 企業信息系統層

企業信息系統包含企業內傳統信息系統如財務，CRM等，特色是有數據庫系統的支持。

 

應用框架目前主要集中在WEB層，旨在規範這一層軟件的開發。其實企業組件層也能夠實現這個模型，但目前主要以設計模式的形式存在。並且有些框架能夠擴充，有了企業組件層組件的參與，框架會顯得更緊湊，更天然，效率會更高。

2. 候選方案

目前，實現模型2的框架也在不斷的涌現，下面列出比較有名的框架。

2.1. Apache Struts

Struts是一個免費的開源的WEB層的應用框架，apache軟件基金致力於struts的開發。Struts具是高可配置的性，和有一個不斷增加的特性列表。一個前端控制組件，一系列動做類，動做映射，處理XML的實用工具類，服務器端java bean 的自動填充，支持驗證的WEB 表單，國際化支持，生成HTML，實現表現邏輯和模版組成了struts的靈魂。

2.1.1. Struts和MVC

模型2的目的和MVC的目的是同樣的，因此模型2基本能夠和MVC等同起來。下圖體現了Struts的運做機理：

 

2.1.1.1. 控制

如圖所示，它的主要部件是一個通用的控制組件。這個控制組件提供了處理全部發送到Struts 的HTTP請求的入口點。它截取和分發這些請求到相應的動做類（這些動做類都是Action類的子類）。另外控制組件也負責用相應的請求參數填充 From bean,並傳給動做類。動做類實現核心商業邏輯，它能夠經過訪問java bean 或調用EJB。最後動做類把控制權傳給後續的JSP 文件，後者生成視圖。全部這些控制邏輯利用一個叫struts-config.xml文件來配置。

2.1.1.2. 模型

模型以一個或幾個java bean的形式存在。這些bean分爲三種：

Form beans(表單Beans)

它保存了HTTP post請求傳來的數據，在Struts裏，全部的Form beans都是 ActionFrom 類的子類。

業務邏輯beans

專門用來處理業務邏輯。

系統狀態beans

它保存了跨越多個HTTP 請求的單個客戶的會話信息，還有系統狀態。

2.1.1.3. 視圖

控制組件續傳HTTP請求給實現了視圖的JSP文件。JSP能訪問beans 並生成結果文檔反饋到客戶。Struts提供JSP 標籤庫： Html，Bean，Logic，Template等來達到這個目的，並有利於分開表現邏輯和程序邏輯。

2.1.2. Struts的細節分析

2.1.2.1. 視圖-控制-模型

用戶發出一個*.do的HTTP請求，控制組件接收到這個請求後，查找針對這個請求的動做映射，再檢查是否曾建立過相應的動做對象（action實例），若是沒有則調用actionmapping生成一個動做對象，控制組件會保存這個動做對象供之後使用。接着調用actionmapping的方法獲得actionForm對象。以後把actionForm做爲參數傳給動做對象的perform方法，這個方法結束以後會返回給控制組件一個 actionforward對象。控制組件接着從這個對象中獲取下一個視圖的路徑和重定向屬性。若是爲重定向則調用HTTPSERVLETREPONSE的方法來顯示下一個視圖，不然相繼調用requestdispatcher, SERVLETcontext的方法續傳HTTP請求到下一個視圖。

當動做對象運行perform方法時，可能出現錯誤信息。動做對象能夠保存這些錯誤信息到一個error對象中，接着調用自身的saveerrors方法把這個錯誤保存到request對象的屬性中。接着動做對象調用actionmapping對象的getInput方法從動做映射中獲取input參數，也就是產生輸入的視圖，並以這個input爲參數生成一個actionforward對象返回。這個input參數的JSP中通常有HTTP:errors定製標籤讀取這些錯誤信息並顯示在頁面上。

 

2.1.2.2. 模型到視圖

模型到視圖指視圖在顯示以前裝載系統數據到視圖的過程。系統數據通常爲模型內java bean的信息。示意圖表現了由控制組件forward過來的有html:form定製標籤的JSP 的處理邏輯。

html:form定製標籤處理對象從application scope（經過查詢SERVLETCONTEXT對象的屬性來實現）獲取先前由控制組件actionSERVLET放在那裏的動做映射等對象，由html:form 的action屬性查得actionform名字、類型和範圍等信息，在相應的範圍內查找actionform，若是有則利用它的信息填充html form表單[實際填充動做在嵌套的html:text等定製標籤的處理對象中]。不然在相應範圍內建立一個actionform 對象。

2.1.3. 優缺點

優勢：

一些開發商開始採用並推廣這個框架

做爲開源項目，有不少先進的實現思想

對大型的應用支持的較好

有集中的網頁導航定義

缺點：

不是業屆標準

對開發工具的支持不夠

複雜的taglib，須要比較長的時間來掌握

html form 和 actionform的搭配比較封閉，但這也是它的精華所在。

修改建議 把actionform屬性的設置器和訪問器修改爲讀取或生成xml文檔的方法，而後 html form和actionform之間用xml文檔進行數據交換，使之鬆散耦合，適應數據結構易變化的應用。

 

2.2. JATO

JATO應用程序框架是iPlanet 應用程序框架的舊名。它是一個成熟的、強大的，基於J2EE標準的面向於開發WEB應用程序的應用框架。結合了顯示字段、應用程序事件、組件層次和以頁面爲中心的開發方法、以及MVC和服務到工做者service-to-workers的設計模式等概念。JATO可適用於中、大、超大規模的WEB應用。可是它也不是一個企業層的應用框架，也就是說它不會直接提供建立EJB, WEB services等企業層組件的方法，但用它能夠構造出訪問企業層組件的客戶應用。

這個框架功能主要有三部分組成：

iPlanet應用框架核心；

iPlanet應用框架組件；

iPlanet應用框架擴展。

應用框架核心定義了基本接口、對象協議、簡單組件，以及iPlanet應用框架程序的最小核心。包括視圖簡單組件、模型簡單組件、請求分發組件和可重用命令對象。iPlanet應用框架組件利用框架核心定義的基本接口、協議和組件向開發者提供高層的重用組件，這些組件既有與特定視覺效果無關的水平組件，同時也有適應特定實用環境、提升可用性而特地提供的垂直型組件。框架擴展實現了用框架相容的方法訪問非J2EE環境的方法。一般狀況下，擴展被框架應用程序用來無縫訪問J2EE容器特定功能。JATO平臺棧圖很清楚地表達了這個狀況。

JATO最大的威力在：對於快速開發用戶，你能利用框架組件和擴展提升生產率，對於要求更大靈活性的用戶，你能實現框架核心提供的接口來保持應用的框架兼容性。

 

此圖表示實現一個JATO應用程序，能夠簡單地實現控制組件module1Servlet，視圖組件ListCustomersViewBean和模型組件CustomersModuleImpl，以及一個給客戶代理顯示界面的ListCustomers.jsp文件。並清楚地代表這些組件與JATO框架組件的繼承關係。

 

JATO標籤庫提供了VIEW對象與JSP文件的接口。庫中標籤處理程序負責實現VIEW對象和JSP產生地客戶端文檔的信息同步和交換。這個圖清楚地表達了這種對應關係

 

前端控制組件接收用戶發來的任何請求，這個可在WEB.xml中指定 請求分發組件負責視圖管理和導航，和前端控制組件封裝在ApplicationSERVLETBase一塊兒實現。應用程序開發者須要爲每個子系統（人力資源，財務，CRM等）實現一個此類的繼承。

請求分發組件分發請求給工做者，工做者實現了command接口。應用開發者能夠實現這個接口。JATO提供了一個缺省實現：DefaultRequestHandingCommand，這個實現會把請求傳給視圖組件的特定事件。

組合視圖是指視圖組件在顯示給用戶時的層次關係：根視圖是一個ViewBean類的對象 字段是一個DisplayField類的對象，容器視圖是一個ContainerView類的對象。視圖組件類的層次關係以下圖：

 

2.2.2. 優缺點分析

優勢：

這種框架的適應範圍大，即提供了底層接口，也有當即可用的組件

具備與客戶端RAD開發工具類似的開發概念如頁爲中心（等同於VB的FORM），事件處理等.

對大型的應用支持較好

缺點：

不是業屆標準

目前尚未開發工具的支持（然JATO已經爲工具支持作好了準備）

沒有定義網頁導航，開發者在視圖中本身指定具體的導航URL

修改建議

把衆多的VIEW/MODEL對應修改爲xml文檔傳遞數據，加上集中的網頁導航定義

2.3. JSF(JavaServer Faces)

JSF是一個包括SUN在內的專家組正在定義的開發WEB應用用戶界面的框架，JSF 技術包括：

一組API，它實現UI了組件，管理組件的狀態，處理事件，輸入校驗，定義頁面導航，支持國際化和訪問；

一個JSP定製標籤庫實現與JSP的接口。

JSF很是簡單，是一個定義良好的編程模型。利用這個技術，開發者經過在頁面內組合可重用的UI組件，在把這些組件和應用的數據源相連，路由客戶產生的事件到服務器端的事件處理器進行編程。JSP處理了全部幕後的複雜工做，使得開發者把關注重點放在應用代碼上。

2.3.1. STRUTS、JATO和JSF比較

它們之間有部分重疊，但重點不同。

STRUTS和JATO都提供了一個MVC式的應用模型，而JSF只在用戶界面上提供編程接口。這意味着前二者涉及的範圍比後者廣。JSF能夠成爲前二者在UI開發的部分。

JSF的規範的發佈版將在 2002年末發佈，實現可能要比這個時間晚些。另外將會有工具支持這個框架的應用開發。

2.4. WAF

WAF是WEB APPLICATION FRAMWORK的簡稱，是SUN藍皮書例子程序中提出的應用框架。它實現了 MVC和其餘良好的設計模式。

2.4.1. 細節分析

 

2.4.2. 視圖-控制-模型

如圖所示，開發人員編寫的兩個xml配置文件定義了WAF的運做參數。Screendefinition.xml定義了一系列的屏幕(screen)。Mapping.xml則定義了某個動做以後應該顯示的屏幕，但沒有指定屏幕到哪裏拿數據。

用戶發出一個HTTP請求（*.screen），由TemplateSERVLET屏幕前端控制組件接收，它提取請求信息，設置request對象CurrentScreen屬性，再把請求發到模版JSP。模版JSP收到請求後，JSP中的Template標籤察看這個當前屏幕，並從屏幕定義文件（Screendefinition.xml）中獲取這個屏幕的具體參數，再生成html返回給客戶。

假設返回給客戶的html中包括了html表單，用戶在輸入必定數據以後提交，發出一個HTTP請求（*.do）。這個請求被MainSERVLET接收，它提取請求信息，察看動做映射文件（mapping.xml），設置處理這個請求的動做對象(HTTPAction對象)，交給requestprosessor對象處理。Requestprosessor對象調用動做對象完成任務，若是須要進一步處理，requestprosessor對象會調用WEBclientcontroler對象的事件處理機制。MainSERVLET在處理完請求以後，從屏幕流管理對象那裏獲得下一個屏幕，並把請求傳給這個屏幕的JSP文件。

值得一提的是WEBclientcontroler事件處理機制最終把HTTP請求的數據傳到了EJBAction對象那裏處理。這樣HTTPAction對象和EJBAction對象造成了兩級處理機制，前一級與request對象緊密相關，把數據封裝起來造成一個Event對象，再傳給了EJBAction對象，後者與Request對象無關。這個方式能夠造成一個session級別的數據處理機制。下圖顯示了這個方法。HTTPAction1對象處理一個請求，並把數據放到一個狀態SessionBean內，HTTPAction2也如此，當HTTPAction3接收到HTTP請求以後，把控制傳給EJBAction, 後者獲取狀態SessionBean數據，處理請求，成功後清控狀態SessionBean的內容。這個機制很是適應多個輸入頁面才能知足一個業務的輸入數據的狀況（好比購物車）。

 

2.4.3. 優缺點分析

優勢

屏幕導航定義明確

爲框架的擴展提供了一個空間

缺點

源碼比較亂，穩定性和可靠性沒人驗證。

只是一個框架軀幹，沒有正式的model層，視圖的概念不強

沒有模型到視圖的定義

修改意見

只有一個框架軀幹，正爲實現本身的應用框架提供了靈活性。沒有僵化的視圖概念，提供了在網頁輸入到模型的擴充接口，好比插入XML數據交換。

 

-----------------------------------------------------------------------

完整的項目源碼來源  歡迎你們一塊兒學習研究相關技術，源碼獲取請加求求:2670716182