痛苦源于
J2EE Web
開發(fā)
互聯網的發(fā)展推動了基于瀏覽器的
B/S
多層體系應用發(fā)展，尤其是眾多
Web2.0
模式網站的涌現，
AJAX
技術的推波助瀾，人們忽然發(fā)現
Web
應用竟然可以如此之美，于是
Web
開發(fā)技術忽如一夜春風來，迅速風靡了
IT
行業(yè)的不同應用領域。隨著分布式技術體系的不斷發(fā)展和完善，
J2EE
作為一個開放的，安全的，可多樣性選擇的分布式計算標準，已經遠遠超越了
.net
和
Corba
，成為企業(yè)信息化系統(tǒng)建設的首選技術體系，并迅速占據了大半壁江山，將競爭對手遠遠的拋在了身后。
當我們逐漸沉迷于
J2EE Web
技術開發(fā)的時候，雖然享受著
J2EE
服務器端編程所帶來高可靠性，安全性和運行期的高效穩(wěn)定性，但隨之痛苦也逐漸而來。當我們一遍遍的用原始的編輯器來編寫
JSP
界面的時候，當我們基于有限的
HTML
界面組件進行編程的時候，才發(fā)現一切并不那么美好，我們的激情開始退卻，開始懷念
VB
，
Delphi
可視化編程的時代
…
當
VB
，
Delphi
時代已經成為過去的時候，我們應如何適應
Web
應用開發(fā)的潮流？也許痛苦將與快樂并存，也許會有更好的解決方式，我們都在期待中
…
我們需要什么
?
作為
Java
的忠誠技術愛好者，我們不需要微軟的
.net
，微軟的
Studio
，雖然它看起來很美，很方便，但不符合我們追求自由和完美的理想主義。我們需要標準，需要技術，但堅決抵制壟斷，我們堅決擁抱
Java
世界所倡導的自由氛圍，一切源于技術，一切源于開放。
隨著
Java EE5
技術標準的推出，
J2EE
技術架構作為服務器端的編程已經被證明是一種可靠的分布式技術標準，而且對開發(fā)人員越來越友好，大大的降低了學習曲線和開發(fā)成本，尤其是
EJB3.0
技術規(guī)范的出臺，更是解決了長期以來存在的
EJB
架構和
O/R Mapping
問題。在
Web
層開發(fā)方面，
JSF
技術將為我們提供一種以組件為中心來開發(fā)
Java Web
用戶界面的方法。
其實我們的需求很簡單，對基于
J2EE Web
應用開發(fā)來說，一個集成式的
J2EE IDE
開發(fā)環(huán)境，能幫助我們很方便的進行業(yè)務邏輯開發(fā)，能方便的進行
Web
應用界面的可視化開發(fā)，并且擁有大量的界面組件。從目前的
Java IDE
開發(fā)環(huán)境來看，都可以滿足基于
Java Bean
或者
EJB
模型的業(yè)務邏輯開發(fā)，但是在
Web
應用界面開發(fā)方面，還沒有一個非常方便易用的可視化
IDE
環(huán)境。
當
JSF
標準出臺后，我們似乎看到了希望，我們相信一切會好起來的。
JSF
看起來很完美
JSF
（
Java Server Faces
）是一種用于構建
Web
應用程序的新標準
Java
框架。它提供了一種以組件為中心來開發(fā)
Java Web
用戶界面的方法，從而簡化了開發(fā)。
JSF
開發(fā)可以簡單到只需將用戶界面
(UI)
組件拖放到頁面上，而
“
系統(tǒng)開發(fā)人員
”
將發(fā)現豐富而強健的
JSF API
為他們提供了無與倫比的功能和編程靈活性。
JSF
還通過將良好構建的模型
-
視圖
-
控制器
(MVC)
設計模式集成到它的體系結構中，確保了應用程序具有更高的可維護性。最后，由于
JSF
是通過
Java Community Process (JCP)
開發(fā)的一種
Java
標準，因此開發(fā)工具供應商完全能夠為
Java Server Faces
提供易于使用的、高效的可視化開發(fā)環(huán)境。
JSF
是否能解決我們長期以來的
Web
開發(fā)之痛呢？它看起來很美，
Sun
為什么會搞出一個
JSF
，
JSF
為什么會是現在這個樣子，我想原因大致可能是這樣的。
首先，基于組件的
Web
開發(fā)將來會是一個趨勢。自包含的組件便于
IDE
的處理，可以提高開發(fā)效率。就是說
JSF
優(yōu)于
Struts/Web Work
這類
MVC
框架的優(yōu)勢，在于它可以與
IDE
結合來自動生成代碼，不需要開發(fā)人員再去關注界面的具體實現，而把精力更集中于界面邏輯控制的實現。而傳統(tǒng)的純手工編寫的
MVC
框架，則影響了開發(fā)效率。
作為界面開發(fā)技術，
Java
在客戶端并沒有明顯的優(yōu)勢。
Applet
已經被拋棄掉，
Java
的強項在服務器端。
Sun
不可能跑去使用
JavaScript
，因為在傳統(tǒng)開發(fā)者眼里，
JS
只配做一點很瑣碎的任務。于是在他們設計的這個架構中，所有的用戶事件都放在了服務器端來處理。這個決策造成了
JSF
致命的缺點，它把事件處理模型綁死在服務器上，限制了響應性更加靈敏的交互設計。隨之而來的網絡延遲會毀掉軟件的可用性。
JSF
技術企圖起到傳統(tǒng)
C/S
應用中
Client
的作用，但由于瀏覽器技術的限制，雖然解決了界面組件化，可視化的問題，但是還遠遠達不到無縫的，靈敏的交互性體驗。
當
JSF
遭遇
AJAX
最近互聯網上比較火熱的話題當然是關于
WEB2.0
的應用，其中
AJAX
又是
WEB2.0
的核心之一。
AJAX
是
Asynchronous JavaScript and XML
的縮寫。它并不是一門新的語言或技術，它實際上是幾項技術按一定的方式組合在一在同共的協作中發(fā)揮各自的作用，它包括：使用
XHTML
和
CSS
標準化呈現；使用
DOM
實現動態(tài)顯示和交互；使用
XML
和
XSLT
進行數據交換與處理；使用
XMLHttpRequest
進行異步數據讀取；最后用
JavaScript
綁定和處理所有數據。
Ajax
的工作原理相當于在用戶和服務器之間加了
—
個中間層，使用戶操作與服務器響應異步化。這樣把以前的一些服務器負擔的工作轉嫁到客戶端，利于客戶端閑置的處理能力來處理，減輕服務器和帶寬的負擔，從而達到節(jié)約
ISP
的空間及帶寬租用成本的目的。
異步請求
/
響應是
Ajax
與傳統(tǒng)開發(fā)方式最大的差別，異步帶來了更好的交互設計。在
Ajax in Action
第
1
章中作者舉了一個令人信服的例子。
Google Maps
中當用戶滾動地圖時，獲取新的地圖圖片，由于是異步請求的，因此不會打斷用戶的操作流程。而在傳統(tǒng)的地圖服務，每次滾動可能都需要刷新頁面。用一下微軟的那個地圖服務就可以感覺到明顯的差距，它甚至根本就不允許用戶滾動地圖。
JSF
的設計思路有點模仿
VB
，組件化的開發(fā)這個方向是沒錯的，
Ajax
開發(fā)將來也會走這條路。但是
JSF
與
VB
最大的差別是
VB
的事件模型都是位于本地來處理的。這是一種本質上的差別，所以如果
JSF
確實想模仿
VB
，那也是東施效顰。而且在
JSF
的設計階段，同步的請求
/
響應是主流，他們的思路仍然牢牢束縛在基于頁面的開發(fā)方式上。根本就沒有思考過其他的可能。
JSF
其實如果和
Applet
結合，可能更好些。
Applet
是多線程的，可以捕獲用戶的操作事件，采用異步方式發(fā)送到服務器。這樣就不會打斷用戶的操作了。但是這樣一來設計的這個架構就復雜了。而且
Applet
是已經決定拋棄的東西。
JSF
和
Java Web Start
結合也可以，不過
JWS
設計用來建造一類完全不同的
Web
應用，即
Rich Client
，而不是設計用來建造運行于瀏覽器之內的
RIA
應用。
從以上分析可以看出，如果
JSF
還是基于目前的技術標準來實現，從長遠來看，最多只是一種過渡方案。未來基于瀏覽器的
RIA
開發(fā)中，
Ajax
、
Flash
是兩種最有前途的技術，最終可能是三分天下，
Ajax
、
Flash/Flex/Laszlo
、還有
MS
的
Atlas
。另外有人會提出疑問，還有
XUL
呢？只要
MS
一天不倒，
XUL
成不了標準，注定會是失敗的，大家看看
Firefox
的市場占有率就可以知道了。
當然，
Ajax
也只是一種客戶端的過渡技術，如果沒有一種很好的
Web
端框架的支持，它也僅僅只能做到一種異步數據傳輸的作用，它解決問題的方法與手段很難形成一種可高度抽象的框架級解決方案，無法形成一個完整的
Web
開發(fā)應用模型，而
JSF
則是一種可擴展的
Web
框架級解決方案。
但當
JSF
遭遇
Ajax
后，這一切將發(fā)生革命性的變化。
JSF
和
Ajax
技術的結合，才能實現高效的，輕量級的
J2EE Web
開發(fā)應用架構，依靠
JSF
的組件和事件模型，
Ajax
的異步通訊方式，共同營造一個體驗好，界面友好的互聯網富客戶端應用環(huán)境。