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資料交換。
願意瞭解框架技術或者原始碼的朋友直接求求交流分享技術：2042849237
分散式的一些解決方案，有願意瞭解的朋友可以找我們團隊探討 。
更多詳細原始碼參考來源：minglisoft.cn/technology