當前流行的J2EE WEB應用架構分析（一）
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.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 對象。
當前流行的J2EE WEB應用架構分析（一）