痛苦源于
J2EE Web
开发
互联网的发展推动了基于浏览器的
B/S
多层体系应用发展，尤其是众多
Web2.0
模式网站的涌现，
AJAX
技术的推波助澜，人们忽然发现
Web
应用竟然可以如此之美，于是
Web
开发技术忽如一夜春风来，迅速风靡了
IT
行业的不同应用领域。随着分布式技术体系的不断发展和完善，
J2EE
作为一个开放的，安全的，可多样性选择的分布式计算标准，已经远远超越了
.net
和
Corba
，成为企业信息化系统建设的首选技术体系，并迅速占据了大半壁江山，将竞争对手远远的抛在了身后。
当我们逐渐沉迷于
J2EE Web
技术开发的时候，虽然享受着
J2EE
服务器端编程所带来高可靠性，安全性和运行期的高效稳定性，但随之痛苦也逐渐而来。当我们一遍遍的用原始的编辑器来编写
JSP
界面的时候，当我们基于有限的
HTML
界面组件进行编程的时候，才发现一切并不那么美好，我们的激情开始退却，开始怀念
VB
，
Delphi
可视化编程的时代
…
当
VB
，
Delphi
时代已经成为过去的时候，我们应如何适应
Web
应用开发的潮流？也许痛苦将与快乐并存，也许会有更好的解决方式，我们都在期待中
…
我们需要什么
?
作为
Java
的忠诚技术爱好者，我们不需要微软的
.net
，微软的
Studio
，虽然它看起来很美，很方便，但不符合我们追求自由和完美的理想主义。我们需要标准，需要技术，但坚决抵制垄断，我们坚决拥抱
Java
世界所倡导的自由氛围，一切源于技术，一切源于开放。
随着
Java EE5
技术标准的推出，
J2EE
技术架构作为服务器端的编程已经被证明是一种可靠的分布式技术标准，而且对开发人员越来越友好，大大的降低了学习曲线和开发成本，尤其是
EJB3.0
技术规范的出台，更是解决了长期以来存在的
EJB
架构和
O/R Mapping
问题。在
Web
层开发方面，
JSF
技术将为我们提供一种以组件为中心来开发
Java Web
用户界面的方法。
其实我们的需求很简单，对基于
J2EE Web
应用开发来说，一个集成式的
J2EE IDE
开发环境，能帮助我们很方便的进行业务逻辑开发，能方便的进行
Web
应用界面的可视化开发，并且拥有大量的界面组件。从目前的
Java IDE
开发环境来看，都可以满足基于
Java Bean
或者
EJB
模型的业务逻辑开发，但是在
Web
应用界面开发方面，还没有一个非常方便易用的可视化
IDE
环境。
当
JSF
标准出台后，我们似乎看到了希望，我们相信一切会好起来的。
JSF
看起来很完美
JSF
（
Java Server Faces
）是一种用于构建
Web
应用程序的新标准
Java
框架。它提供了一种以组件为中心来开发
Java Web
用户界面的方法，从而简化了开发。
JSF
开发可以简单到只需将用户界面
(UI)
组件拖放到页面上，而
“
系统开发人员
”
将发现丰富而强健的
JSF API
为他们提供了无与伦比的功能和编程灵活性。
JSF
还通过将良好构建的模型
-
视图
-
控制器
(MVC)
设计模式集成到它的体系结构中，确保了应用程序具有更高的可维护性。最后，由于
JSF
是通过
Java Community Process (JCP)
开发的一种
Java
标准，因此开发工具供应商完全能够为
Java Server Faces
提供易于使用的、高效的可视化开发环境。
JSF
是否能解决我们长期以来的
Web
开发之痛呢？它看起来很美，
Sun
为什么会搞出一个
JSF
，
JSF
为什么会是现在这个样子，我想原因大致可能是这样的。
首先，基于组件的
Web
开发将来会是一个趋势。自包含的组件便于
IDE
的处理，可以提高开发效率。就是说
JSF
优于
Struts/Web Work
这类
MVC
框架的优势，在于它可以与
IDE
结合来自动生成代码，不需要开发人员再去关注界面的具体实现，而把精力更集中于界面逻辑控制的实现。而传统的纯手工编写的
MVC
框架，则影响了开发效率。
作为界面开发技术，
Java
在客户端并没有明显的优势。
Applet
已经被抛弃掉，
Java
的强项在服务器端。
Sun
不可能跑去使用
JavaScript
，因为在传统开发者眼里，
JS
只配做一点很琐碎的任务。于是在他们设计的这个架构中，所有的用户事件都放在了服务器端来处理。这个决策造成了
JSF
致命的缺点，它把事件处理模型绑死在服务器上，限制了响应性更加灵敏的交互设计。随之而来的网络延迟会毁掉软件的可用性。
JSF
技术企图起到传统
C/S
应用中
Client
的作用，但由于浏览器技术的限制，虽然解决了界面组件化，可视化的问题，但是还远远达不到无缝的，灵敏的交互性体验。
当
JSF
遭遇
AJAX
最近互联网上比较火热的话题当然是关于
WEB2.0
的应用，其中
AJAX
又是
WEB2.0
的核心之一。
AJAX
是
Asynchronous JavaScript and XML
的缩写。它并不是一门新的语言或技术，它实际上是几项技术按一定的方式组合在一在同共的协作中发挥各自的作用，它包括：使用
XHTML
和
CSS
标准化呈现；使用
DOM
实现动态显示和交互；使用
XML
和
XSLT
进行数据交换与处理；使用
XMLHttpRequest
进行异步数据读取；最后用
JavaScript
绑定和处理所有数据。
Ajax
的工作原理相当于在用户和服务器之间加了
—
个中间层，使用户操作与服务器响应异步化。这样把以前的一些服务器负担的工作转嫁到客户端，利于客户端闲置的处理能力来处理，减轻服务器和带宽的负担，从而达到节约
ISP
的空间及带宽租用成本的目的。
异步请求
/
响应是
Ajax
与传统开发方式最大的差别，异步带来了更好的交互设计。在
Ajax in Action
第
1
章中作者举了一个令人信服的例子。
Google Maps
中当用户滚动地图时，获取新的地图图片，由于是异步请求的，因此不会打断用户的操作流程。而在传统的地图服务，每次滚动可能都需要刷新页面。用一下微软的那个地图服务就可以感觉到明显的差距，它甚至根本就不允许用户滚动地图。
JSF
的设计思路有点模仿
VB
，组件化的开发这个方向是没错的，
Ajax
开发将来也会走这条路。但是
JSF
与
VB
最大的差别是
VB
的事件模型都是位于本地来处理的。这是一种本质上的差别，所以如果
JSF
确实想模仿
VB
，那也是东施效颦。而且在
JSF
的设计阶段，同步的请求
/
响应是主流，他们的思路仍然牢牢束缚在基于页面的开发方式上。根本就没有思考过其他的可能。
JSF
其实如果和
Applet
结合，可能更好些。
Applet
是多线程的，可以捕获用户的操作事件，采用异步方式发送到服务器。这样就不会打断用户的操作了。但是这样一来设计的这个架构就复杂了。而且
Applet
是已经决定抛弃的东西。
JSF
和
Java Web Start
结合也可以，不过
JWS
设计用来建造一类完全不同的
Web
应用，即
Rich Client
，而不是设计用来建造运行于浏览器之内的
RIA
应用。
从以上分析可以看出，如果
JSF
还是基于目前的技术标准来实现，从长远来看，最多只是一种过渡方案。未来基于浏览器的
RIA
开发中，
Ajax
、
Flash
是两种最有前途的技术，最终可能是三分天下，
Ajax
、
Flash/Flex/Laszlo
、还有
MS
的
Atlas
。另外有人会提出疑问，还有
XUL
呢？只要
MS
一天不倒，
XUL
成不了标准，注定会是失败的，大家看看
Firefox
的市场占有率就可以知道了。
当然，
Ajax
也只是一种客户端的过渡技术，如果没有一种很好的
Web
端框架的支持，它也仅仅只能做到一种异步数据传输的作用，它解决问题的方法与手段很难形成一种可高度抽象的框架级解决方案，无法形成一个完整的
Web
开发应用模型，而
JSF
则是一种可扩展的
Web
框架级解决方案。
但当
JSF
遭遇
Ajax
后，这一切将发生革命性的变化。
JSF
和
Ajax
技术的结合，才能实现高效的，轻量级的
J2EE Web
开发应用架构，依靠
JSF
的组件和事件模型，
Ajax
的异步通讯方式，共同营造一个体验好，界面友好的互联网富客户端应用环境。