当JSF遭遇Ajax (zt)

linkxiong

当JSF遭遇Ajax

原文作者 :
create2000
发表时间 : 2006-11-24
痛苦源于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的异步通讯方式，共同营造一个体验好，界面友好的互联网富客户端应用环境。

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/14788/showart_208601.html