1.webx框架的基礎知識
1.1.框架整體理解
從整體上來說，webx框架是一個可定製可擴展的javaEE框架。爲什麼說它是可定製可擴展的，其根本原因在於webx框架的層次性和繼承性的，webx分爲3大層次，SpringExt，Webx Framework和Webx Turbine。從SpringExt到Webx Framework再到Webx Turbine，一層一層的擴展，在原來的層次基礎上添加功能。從上層到下層整體來說和繼承機制像類似，Webx Framework繼承了SpringExt，而Webx Turbine又繼承了Webx Framework。在繼承的過程中通過使用OCP原則使得子層次的結構完全兼容父層次的結構，只是在原來的結構上添加了一些額外的功能。正是這種層次化，繼承化的框架結構使得webx框架可定製和可擴展。
因爲其可定製可擴展的特點，在使用框架的時候可以只使用SpringExt框架，或者使用Webx Framework框架，或者使用全部的WebxTurbine框架。或者，可以在Webx Framework結構上不使用Webx Turbine的那一套網頁渲染方式，而是用另外的一套網頁渲染方式。靈活性很強。
因爲所有層析結構的原始結構都是Spring，所以不管哪個層次的結構，其框架的啓動方式和服務方式是統一的。在應用啓動的時候，會加載一個Spring容器到內存中，並且默認的在容器中添加一些用於服務的Service Bean，這些Service Bean會通常在整個生命週期中存在並提供各項服務。對於不同的層次，其Service會有各種不同的擴展，比如在SpringExt層次中有用於加載資源的ResourceLoaderService，在Webx Framwork層次中擴展了用於控制整個應用流程的Pipeline Service，在Webx Turbine層次中又擴展了用於加載模塊的ModuleLoaderService。這些service都會有與其對應的Service Bean在Spring容器加載的時候被添加到Spring容器中，有時候這些Service Bean也會被注入到應用中具體的Bean中去，爲其提供服務。
1.2框架中的各種服務和特性
我們現在的項目中通常都是使用整個Webx 框架來進行項目開發，所以對於之前提到的三層結構，我們用的是最外層，即Webx Turbine結構。對於每一層的service都可以進行使用，這樣形成一個比較龐大的框架體系。用到的service如下：
- Form Service —— 提供基於HTML form的表單驗證功能。
- Template Service —— 提供基於文本的模板渲染的功能。
- JSP Service —— 基於JSP的模板引擎，和Template Service配合，渲染JSP格式的模板文件。
- Velocity Service —— 基於Velocity的模板引擎，和Template Service配合，渲染Velocity格式的模板文件。
- Pipeline Service —— 讀取配置，創建pipeline。Pipeline是一種可配置的程序流程控制技術，被webx用來控制HTTP請求的流程。
- Mail Service —— 通過配置和編程的方法，方便地創建、發送、接收符合RFC標準的e-mail。
- Pull Service —— 實現Pull-MVC的設計模式。
- RunData Service —— 將HTTP請求中的諸多對象包裝成一個更易於使用的接口，並且對HTTP response實現了buffer機制，是頁面cache技術和頁面layout技術的基礎。
- Upload Service —— 處理multipart/form-data類型的HTTP request。
- URIBroker Service —— 動態生成任意類型的URL和URI。
這些service各司其職，爲我們提供有效的服務。我們在應用中要使用這些service的時候需要在webx.xml中對其進行配置，這樣在Spring容器加載的時候才能加載這些service，後面纔可以對該service進行使用。下面對幾個比較重要的service進行描述。
1.2.1Resource Loading Service
資源表現形式的多樣性，給應用程序的接口設計帶來一點麻煩，爲了統一資源的獲取，Spring框架中提供這方面的服務，即Resource Loader，但是Resource Loader還存在一些不合理的地方，於是webx中提供了Resource Loading Service對資源進行統一管理，在Resource Loading Service中可以包含多個不同的Resource Loader進行資源的加載，使得加載資源具有多樣性，同時也很好的完成了資源加載的大部分功能。
並且在ResourceLoading的服務中添加了XML Shema及其解釋器，使得對於資源的裝配的配置文件寫起來更加清晰易讀，而且修改和維護性增強。
1.2.2 Request Contexts Service
RequestContexts Service是對servlet中的Filter的擴展，作用是對請求進行預處理。該服務負責訪問和修改request和response，但是不負責改變應用執行的流程，改變應用執行的流程則是另一個對Filter擴展的Service: Pipeline Service來完成。
Request ContextsService的核心是Request Contexts，Request Context是對HttpServletRequest和HttpServletResponse這兩個對象的封裝，將有多個Request Context嵌套，就好像一個filter chain一樣，從內到外一步一步執行，直到最後形成一個較大的Request Context用來處理，在處理結束以後，再從外到內一步一步執行，將Response返回。
1.2.3 Pipeline Service
Pipeline service通過Value的控制，提供應用執行的流程，但不關心request和response。Request和Response的處理交給 Request Contexts Service來做。
Pipeline service控制着整個應用的運行流程，Pipeline和Action一起在MVC結構中起到了一個Controller的作用，對整個應用的走向進行控制。
1.2.4 Form Service
Form Service是對錶單的驗證的服務，這是webx中一個極其重要的服務，將驗證邏輯和表現邏輯分離。
在form.xml中詳細的定義了表單驗證的要求，並定義了相應驗證模塊Group。
將form.xml中定義的group在頁面模板中創建出其實例。
在用戶填寫完表單進行提交操作的時候需要在Action中注入FromService的實例，並通過fromService對錶單進行驗證。
以上是一個簡單的form service的使用場景，對於form service還有一些更加深層次的應用。比如國際化之類的使用。form service很好的解決了表單驗證的代碼冗雜問題，在表單的驗證方面是一個很好的服務。
1.2.5 URIBroker Service
URIBroker Service的作用是對於應用中的URI進行統一的管理，比如由AnalyzeURLValve來分析請求URL，還可以動態的生成URI，而擁有以下的好處：
• 集中管理 —— 全網站的URL均可在同一個配置文件中管理
• 可靠 —— 動態生成，不容易出錯
• 規範 —— 例如在生成query string時，會自動URL encoding
• 透明 —— 應用程序、模板不需要知道最終生成的URL的樣子，修改URL就變得很簡單
URI的用法如下：
- 取得URIBrokerService：
URIBrokerServiceuriBrokerService = (URIBrokerService)
getWebxComponent()
getService(URIBrokerService.SERVICE_NAME);
- 取得指定名稱的URIBroker：
URIBrokeruriBroker = uriBrokerService.getURIBroker(
"petstoreLoginLink", rundata);
- 渲染URL：
Stringurl = uriBroker.render();
1.2.6.Template Service
對於前臺的顯示，使用了Velocity渲染技術，將頁面靜態設計和頁面的動態數據呈現分離，通過模板技術和pull技術使得界面可以先於程序優先設計，並且將這兩個方面脫離使得維護的成本降低。
模板方面如下：由layout，control和screen組成。而相應的Java代碼中由screen，control和action組成。
對於頁面的渲染過程如下：
1.3.應用整體結構
從上面這個數據流來看，用戶首先通過對於view的操作將http request發送到服務器，在服務器端首先要進行一系列的處理，比如Request Context Service對http request的處理，Pipeline service對流程的處理等等，以上這些處理都可以放在WebxController層裏。
經過webxController的這些處理以後調用兩個方面，一個是screen進行渲染，另一個是調用action進行請求的處理。如果是screen進行渲染，則使用Template Service將頁面渲染呈現出來。如果是調用action進行請求處理，則需要在action中繼續調用AO來進行後臺的處理，在調用AO的時候使用Command模式。AO繼續調用Biz層，將處理交給業務邏輯，業務邏輯在調用數據持久化層，即DAO進行數據訪問。
整個流程如上圖所示，從最前面到最後面，再依次返回。Webx最具特點的是其WebxController層，其中包含了上面所講的衆多service，通過這些service對應用進行整體的控制，而到後面的業務邏輯層以後，就和大多數J2EE框架類似了。
2.總結
說一下對於整個webx框架學習後的感受吧。
2.1.WEBX的規模
首先，webx框架是一個比較重量級的企業級JavaEE應用框架。說其重量級，是指使用webx的整體功能。當然如果像一開始說的那樣，僅使用其SpringEx層次的部分，則沒有這麼龐大。當然在淘寶和阿里巴巴裏，大多數web項目使用的是就是整個webx的框架。對於這樣一個重量級的框架，有人說它臃腫，對，確實是臃腫，但這卻是必須的。
我覺得，一個企業級的應用和一個簡單應用相比，最大的差別是對於代碼的維護方式是不同的。企業級應用中，對於一個項目往往需要好多人來共同維護，或者說在項目重構的時候的開發人員和上一版本的開發人員很有可能沒有交集。這樣，如何去讀懂前人的代碼，如何去修改其他人的代碼則成了一個比較嚴重的問題。
而從另一方面來看，一個重量級框架和輕量級框架相比，最大的差別是在於功能實現以及層次劃分和模塊獨立方面是不同的。一個重量級框架擁有着各種服務代碼(即service)，很多東西都不需要進行編寫，直接在配置文件中加載服務即可實現功能。另一方面來說，一個重量級框架是層次清晰的，各個層次的耦合度比較低，模塊和模塊之間相對比較獨立。
這樣，對於一個企業級的應用來說，是需要一個重量級框架的。雖然對於重量級框架的學習成本比較高，但是一旦新人深入學習了框架的內容，則可以在很多情況下方便的使用框架來組織自己的應用。通過對已有的Service的調用，使得所有開發人員在該Service的功能的實現方面不需要自己進行代碼編寫，從而保持代碼的標準化和統一性。這樣，一是提高了開發人員在閱讀已有代碼時的效率。二是提高了開發人員編寫代碼，組織應用的效率。三則是通過減少新開發代碼的代碼量，降低了Debug發生的概率，使得穩定性上升。
總的來說，一個重量級的框架雖然看上去臃腫，卻很合適這種開發人員衆多的企業級應用。
2.2.WEBX的特點
WebX相比於很多其他的JavaEE框架，比較明顯的特點在於其的定製和擴展特性。WebX的核心是Spring容器，其他幾乎所有的功能都是通過Service的方式來完成的。而每個Service實際上就是在Spring容器中的一個個Service Bean。這些Service是多可少的，全憑在配置文件中配置。這樣，每一個應用就可以選取與自身相關的Service進行使用，對於不需要的Service完全可以不予加載。這就使得應用可以根據需要定製自身的Service羣。另一方面，隨着技術的日益發展，很多舊的功能都需要淘汰，而很多新的功能需要加入。通過WebX的Service機制，可以很好的做到這一點。所有的Service就好象插件一樣，對於不需要的舊的Service可以進行去除，而對於新的好的Service可以給予加入。這樣就很好的擴展了現有的結構，使得webx框架不斷進步。