3年前，“Spring之父”Rod.Johnson寫了一本在Java界引起轟動的書：《Expert One-on-One J2EE Development Without EJB》。
這本書闡述了EJB作為J2EE核心技術所帶來的意義與價值，但作者用了更大篇幅介紹EJB的一些缺陷與不足，並提出了Without EJB的解決方案。正是由於“J2EE Without EJB”這個激動人心的口號及這本書奠定的基礎，導致了Spring Framework這個經典輕量級框架的誕生。
2年前，Ajax開始進入人們的視野。時至今日，Ajax已經成為一個紅得發紫的技術。但是今天，我想說一句：JavaEE without Ajax。
Ajax的“原罪”
Ajax為什麼這樣紅?有人說，是因為起了個好聽易記的名字(比如荷蘭著名的Ajax球隊，即阿賈克斯);也有人說，是因為Google全新的Ajax應用產品給人們帶來的超酷體驗(比如偉大的Google Maps、GMail等)。確實如此，Ajax能夠如此流行的最主要原因就是它帶來了更好的用戶體驗，改變了人們對傳統Web應用的不佳印象。然而，即使Ajax的狂熱Fans也不得不承認的是，從技術層面上來說，Ajax並沒有帶來什麼新鮮的東西。它本質上是一種新瓶裝舊酒的技術，好處是通過Java Script與DHTML提供了一種異步編程模型，從而使Web應用給客戶帶來了更好的人機體驗。正如我在去年引起大家爭論的拙文《Ajax，只是一種過渡技術》中表述的：Ajax解決問題的層面較低。或者說，它解決問題的方法與手段，很難形成一種可高度抽象的框架級解決方案。並且，正是因為Ajax基於Java Script，因此不可避免地帶來了Java Script的諸多缺點，譬如：
- 跨浏覽器是一場噩夢
- 對搜索引擎的支持不好
- 干掉了Back、History等按鈕(盡管我並不認為Back、History是什麼好東西)
- 開發與維護成本過高
要Java, 不要Java Script
We Love Java, Not Java Script。套用毛澤東的慣用句式就是：“要Java, 不要Java Script”。相信很多讀者看完這個標題也許會不以為然，但這句話卻代表了許多J2EE開發人員的心聲。
眾多Java工程師都對Java有一種近乎偏執的喜愛，他們熱愛Java的簡潔與優雅。但一旦讓他們去進行Java Script的開發，卻往往會不知所措：過度靈活的語法，無法通過編譯器進行語法校驗，缺乏良好的調試工具等等這些，都會讓人們對Java Script畏手畏腳，更遑論Ajax的開發。
一句話，Java社區需要Ajax，需要它來提升基於JavaEE的Web應用的人機體驗;但是，人們並不喜歡Ajax目前的開發模式。無疑，我們需要一種新的解決方案。
誰來拯救JavaEE的Ajax?
我給出的答案是JSF。目前，關於JSF的一種流行說法是“悲劇人生：Sun讓JSF光著身子降臨到Java Web世界”。然而，我的看法卻是：作為一種革命性的服務器端組件技術，JSF猶如早晨八九點鐘的太陽，前途不可限量。
讓事實說話，我們先來看看JSF請求/響應過程的標准生命周期：
圖1：JSF的生命周期
通過上圖可以觀察到，任何一個JSF“Faces Request” 請求，經過Restore View、Apply Request Values、Process Validations、Update Models、Invoke Application等階段以後，產生了一個 “Render Response” 返回給客戶端。那麼，常規JSF引擎是如何實現上述過程的呢?
圖2：常規JSF引擎的請求與響應過程
回顧一下常規JSF引擎針對請求與響應的過程：首先，客戶端請求某個資源，產生一個Faces Request;服務器端接收到此請求以後，經過一系列後台處理，產生一個Faces Response。我們注意到：響應的Content-Type是text/html，而產生的內容主體是一段HTML文本;浏覽器在接收到HTML文本以後，進行整個頁面的渲染與刷新。
無需寫Ajax代碼的Ajax Enabled應用
我用自己開發的JSF引擎，這樣處理上述過程(詳見參考資料www.OperaMasks.org )，如下圖所示：
