3年前，“Spring之父”Rod.Johnson寫了一本在Java界引起轟動的書：《Expert One-on-One J2EE Development Without EJB》。這本書闡述了EJB作為J2EE核心技術(shù)所帶來的意義與價值，但作者用了更大篇幅介紹EJB的一些缺陷與不足，并提出了Without EJB的解決方案。正是由于“J2EE Without EJB”這個激動人心的口號及這本書奠定的基礎(chǔ)，導(dǎo)致了Spring Framework這個經(jīng)典輕量級框架的誕生。

2年前，Ajax開始進入人們的視野。時至今日，Ajax已經(jīng)成為一個紅得發(fā)紫的技術(shù)。但是今天，我想說一句：JavaEE without Ajax。


Ajax的“原罪”

Ajax為什么這樣紅？有人說，是因為起了個好聽易記的名字（比如荷蘭著名的Ajax球隊，即阿賈克斯）；也有人說，是因為Google全新的Ajax應(yīng)用產(chǎn)品給人們帶來的超酷體驗（比如偉大的Google Maps、GMail等）。確實如此，Ajax能夠如此流行的最主要原因就是它帶來了更好的用戶體驗，改變了人們對傳統(tǒng)Web應(yīng)用的不佳印象。

然而，即使Ajax的狂熱Fans也不得不承認的是，從技術(shù)層面上來說，Ajax并沒有帶來什么新鮮的東西。它本質(zhì)上是一種新瓶裝舊酒的技術(shù)，好處是通過Java Script與DHTML提供了一種異步編程模型，從而使Web應(yīng)用給客戶帶來了更好的人機體驗。正如我在去年引起大家爭論的拙文《Ajax，只是一種過渡技術(shù)》中表述的：Ajax解決問題的層面較低。或者說，它解決問題的方法與手段，很難形成一種可高度抽象的框架級解決方案。并且，正是因為Ajax基于Java Script，因此不可避免地帶來了Java Script的諸多缺點，譬如：

跨瀏覽器是一場噩夢

對搜索引擎的支持不好

干掉了Back、History等按鈕（盡管我并不認為Back、History是什么好東西）

開發(fā)與維護成本過高

要Java, 不要Java Script

We Love Java, Not Java Script。套用毛澤東的慣用句式就是：“要Java, 不要Java Script”。相信很多讀者看完這個標題也許會不以為然，但這句話卻代表了許多J2EE開發(fā)人員的心聲。

眾多Java工程師都對Java有一種近乎偏執(zhí)的喜愛，他們熱愛Java的簡潔與優(yōu)雅。但一旦讓他們?nèi)ミM行Java Script的開發(fā)，卻往往會不知所措：過度靈活的語法，無法通過編譯器進行語法校驗，缺乏良好的調(diào)試工具等等這些，都會讓人們對Java Script畏手畏腳，更遑論Ajax的開發(fā)。

一句話，Java社區(qū)需要Ajax，需要它來提升基于JavaEE的Web應(yīng)用的人機體驗；但是，人們并不喜歡Ajax目前的開發(fā)模式。無疑，我們需要一種新的解決方案。



誰來拯救JavaEE的Ajax？

我給出的答案是JSF。目前，關(guān)于JSF的一種流行說法是“悲劇人生：Sun讓JSF光著身子降臨到Java Web世界”。然而，我的看法卻是：作為一種革命性的服務(wù)器端組件技術(shù)，JSF猶如早晨八九點鐘的太陽，前途不可限量。

讓事實說話，我們先來看看JSF請求/響應(yīng)過程的標準生命周期


圖1：JSF的生命周期



通過上圖可以觀察到，任何一個JSF“Faces Request” 請求，經(jīng)過Restore View、Apply Request Values、Process Validations、Update Models、Invoke Application等階段以后，產(chǎn)生了一個 “Render Response” 返回給客戶端。那么，常規(guī)JSF引擎是如何實現(xiàn)上述過程的呢？


圖2：常規(guī)JSF引擎的請求與響應(yīng)過程



回顧一下常規(guī)JSF引擎針對請求與響應(yīng)的過程：首先，客戶端請求某個資源，產(chǎn)生一個Faces Request；服務(wù)器端接收到此請求以后，經(jīng)過一系列后臺處理，產(chǎn)生一個Faces Response。我們注意到：響應(yīng)的Content-Type是text/html，而產(chǎn)生的內(nèi)容主體是一段HTML文本；瀏覽器在接收到HTML文本以后，進行整個頁面的渲染與刷新。


無需寫Ajax代碼的Ajax Enabled應(yīng)用

我用自己開發(fā)的JSF引擎，這樣處理上述過程（詳見參考資料www.OperaMasks.org ），如下圖所示：


圖3：OperaMasks JSF實現(xiàn)的請求與響應(yīng)過程


首先可以觀察到，F(xiàn)aces Request的發(fā)出是基于“x-requested-by: XML Http Request”，也就是說，這是一個Ajax請求，而該請求在到達服務(wù)器端以后，服務(wù)器端所產(chǎn)生的Faces Response同常規(guī)Faces Response相比也發(fā)生了變化：Content-Type不再是text/html，變成了text/javascript；并且，響應(yīng)的主體也不再是html文本，而是一堆script腳本。瀏覽器在接收到響應(yīng)以后，再也不需要進行整個頁面的渲染與刷新，而只僅僅需要執(zhí)行這段腳本內(nèi)容，將頁面的控件進行更新即可。

顯而易見，通過上述JSF技術(shù)，我們獲得了：

基于Ajax的請求、應(yīng)答、及頁面控件的更新

數(shù)據(jù)傳輸量明顯減少

避免整個頁面的刷新，更好的用戶體驗

系統(tǒng)保持敏捷、高效



換言之：任何標準JSF應(yīng)用，只需將其在OperaMasks JSF引擎上運行，就可以達到這樣的效果。我們并沒有寫任何一行Ajax的代碼，但是，我們的應(yīng)用卻是自然而然的Ajax Enabled的應(yīng)用。大道至簡，大象無形。



奧妙所在：JSF的Render機制

為什么可以這樣？

JSF組件只是特定狀態(tài)和行為的載體，而組件以什么形式去和用戶交互，是完全可定制的、獨立于該特定的表現(xiàn)語言，可以是HTML、WML或者其他形式；具體是什么，可以通過指定JSF組件的Render Kit來實現(xiàn)，而每一種Render Kit，對應(yīng)于組件作者寫的同一風(fēng)格和形式的一系列Render。

比如，如果想在網(wǎng)頁中實現(xiàn)圖表功能（Chart)，MSIE有VML，Gecko和Opera有SVG；而在服務(wù)器端只需要簡單地判斷一下瀏覽器類型，就可以選擇一個Render Kit，生成不同的客戶端表現(xiàn)來完成相同功能――這是用常規(guī)JSP技術(shù)很難完成的任務(wù)。

通俗的說，JSF組件可以翻譯成任何你想要的形式。So，JSF框架比現(xiàn)有其它開源框架具有更強的生命力。上文所述的OperaMasks JSF，其容器級別Ajax實現(xiàn)，正是靈活應(yīng)用Render Kit的具體案例。



從容器級別對Ajax予以支持的JSF引擎

我們提出的JSF是直接由JSF容器來處理Ajax請求的，它會根據(jù)請求類型來判斷這是一個正常HTTP請求還是一個 Ajax請求：如果是常規(guī)HTTP請求就運行JSP頁面，生成頁面文檔（特定的，對于Ajax Render kit，要加入一些Ajax基礎(chǔ)JavaScript代碼）；如果是Ajax請求，服務(wù)器對請求參數(shù)正常解碼，并執(zhí)行JSF中除頁面輸出階段以外的所有其他階段，生成一個JSF組件樹。

一直到這一步為止，處理方式與對普通HTTP請求的處理完全一致，唯一不同的是：在隨后Render Response階段，容器除了調(diào)用組件作者寫的Ajax功能 Renderer以外，更重要的是在生成響應(yīng)頁面時，會過濾掉一切不會變化的靜態(tài)內(nèi)容――也就是說，靜態(tài)內(nèi)容不會生成到響應(yīng)頁面中去，而對每一個動態(tài)內(nèi)容則會生成一個相應(yīng)JavaScript代碼（可以更進一步優(yōu)化為只有變化了的動態(tài)內(nèi)容才處理）。這樣，傳給客戶的Ajax應(yīng)答實際上是由這樣一些JavaScript語句構(gòu)成。在Ajax響應(yīng)返回到客戶端時，就可以自動由Ajax回調(diào)函數(shù)執(zhí)行這些JavaScript語句，完成對頁面即時的、局部的更改，而不需要刷新整個頁面。依賴JSF組件的具體功能，甚至可以改變頁面的外觀。而整個Ajax機制由JSF引擎提供，對用戶完全透明。

實際上，在JSF規(guī)范中JSF頁面輸出階段所采用的Render Kit是可替換的，默認的HTML_BASIC Render Kit輸出的是標準HTML語法，不包含任何Java Script代碼。我們提出的JSF引擎實現(xiàn)了一個 Ajax Render Kit，可以在HTML文檔中嵌入Java Script代碼來實現(xiàn)Ajax特性，而替換Render Kit只需要修改配置文件即可。

簡單地說，這種JSF引擎為每個標準組件都實現(xiàn)了相應(yīng)的Ajax Render， 比如對UICommand組件，其Ajax Render會在onclick事件中加入JavaScript的Ajax提交代碼，向服務(wù)器提交Ajax請求。通過這種方式，任何一個包含標準JSF組件的Web應(yīng)用，都可以通過只更改Render Kit配置為Ajax來實現(xiàn)Web應(yīng)用Ajax化。而對于第三方的組件，可能本身并不支持 Ajax，但使用一個名為<Ajax:renderGroup>的標簽，就可以立即將這個第三方組件轉(zhuǎn)換成Ajax Enabled。

例如，Apache myfaces的Tomahawk項目提供了一個Tree組件，這個組件本身并不支持Ajax，每當(dāng)按下一個Tree結(jié)點都將重新刷新整個頁面。使用<Ajax:renderGroup>標簽后，則只刷新Tree部分，而不刷新頁面的其他部分。當(dāng)然更好的方式是，提供一個本身就支持Ajax的Tree組件，以減少冗余數(shù)據(jù)的傳遞。關(guān)于<Ajax:renderGroup>標簽的原理，有興趣的讀者可以參考OperaMasks JSF的源碼（詳見參考資料），這里就不再一一贅述了。

綜上，JavaEE 需要Ajax，但并不需要傳統(tǒng)的Ajax開發(fā)模式。通過我們提出的OperaMasks JSF技術(shù)，我們不再需要知道什么是Ajax，而我們的應(yīng)用卻是自然而然的Ajax Enabled應(yīng)用。

因此，我們認為：JavaEE Without Ajax！