假设您需要创建一个适合 Web 2.0 环境的新应用程序。一部分用户非常喜欢基于 HTML 的用户界面，而其他用户希望他们使用的每个应用程序都表现得像 Excel 那样的桌面应用程序。您的老板要求有工作效率高的用户体验，但是 CIO 不允许开发需要用户手工部署的任何东西。您知道 HTML 无法达到这样的目标，但是怎么做才能符合要求呢？本文要讨论一系列 Web 2.0 用户界面技术，让您构建的应用程序具有比浏览器更好的用户体验。而且，可以像任何其他 Java™ 2 Enterprise Edition（Java EE）应用程序一样集中地部署和管理它们。
在用户界面方面，当今的企业应用程序开发人员受到来自用户和运营部门的双重压力。一方面，代表用户的业务部门希望应用程序具有丰富的用户界面，能够最大限度地提高用户的工作效率。他们希望所有应用程序都表现得像 Microsoft 的 Excel 或者其他客户机应用程序一样。希望应用程序能够提供即时响应。此外，若有相同数据的多个视图（例如，一个表格视图和一个图形视图），那么还希望在其中一个视图中进行修改时，其他视图能够立即反映出这一修改。
另一方面，IT 运营部门喜欢纯粹的基于服务器的交付模型。尽管他们知道 HTML 用户体验不如基于本机操作系统（OS）的用户界面那么健壮，但他们认为为了改进用户体验，安装、配置和管理客户机代码的成本太高了。
IT 组织中的许多人都亲身体验过 20 世纪 90 年代的客户机/服务器部署模型，不愿意再重复那样的经历。实际上，如果有客户机组件存在，许多 Java 2 Enterprise Edition（Java EE）应用程序可能不会构建起来，因为成本对于应用程序的业务目标来说太高了。服务器交付的部署模型为 IT 组织提供了低成本高效率的部署方式，这在 90 年代是 IT 组织的梦想。大多数组织都意识到了服务器部署的 Java EE 应用程序的经济优势，因此根本不会考虑部署那些必须在各个客户机上进行安装的代码，除非是不得已。
那么，企业开发人员应该怎么做呢？用户不希望由于几秒的服务器响应时间而降低工作效率，而 IT 部门又不同意采用在客户机上部署和管理代码的老方法。如何能够满足这些表面上相互冲突的需求，让双方都满意呢？
幸运的是，现有的技术使您能够提供比浏览器更好的用户体验，同时不必在客户机上手工安装代码。用这些技术构建的应用程序有时候被称为 Web 2.0 应用程序。在 Tim O'Reilly 的文章 “What Is Web 2.0? Design Patterns and Business Models for the Next Generation of Software” （参见 参考资料）中，他指出：
我们正在进入一个前所未有的用户界面革新时代，Web 开发人员最终能够构建出与本地 PC 应用程序同样丰富的 Web 应用程序。
Web 2.0 应用程序同时提供了两种环境的优点：低成本高效率的基于服务器的部署模型，以及几乎可以与客户机应用程序媲美的用户体验。
对于为当今的 Java EE 应用程序提供丰富的用户体验，有几种技术可供选择：
- Flex 和 OpenLaszlo
- IBM® Workplace™ Managed Client 和 IBM Lotus® Expeditor
- Faces Client Components
- Ajax
- HTML
Flex 和 OpenLaszlo
Flex 和 OpenLaszlo 是极其相似的声明式方法，用来为 Java EE 应用程序创建比浏览器更好的用户体验。Flex 由 Adobe/Macromedia 提供，而 OpenLaszlo 是最初由 Laszlo Systems Inc 创建的开放源码软件。在这两种环境中，都使用独特的基于 XML 的语法来布置和创建用户界面。
例如，为了在 Flex 中使用一个按钮，可以用 MXML（Multimedia XML）编写以下代码：<a name="code-text"><mx:Button label="Submit"</mx:Button></a>
而对于 OpenLaszlo，可以用 LZX（LasZlo XML）编写以下代码：<a name="code-text"><button<Submit</ button></a>
为了允许不同的 UI 元素与服务器进行交互和通信，可以用 ActionScript（Flex）或 JavaScript（OpenLaszlo）编写脚本。
尽管这两种技术有许多相似性，但关键的一点差异是它们需要的运行时基础设施。对于需要与服务器交换数据的客户机，Flex 需要一个 Flex Data Services Server，它与 Flash Player 插件中运行的客户机进行通信。在本质上，这个服务器为客户机和应用程序的服务器组件之间的所有通信和数据交换提供中介。
OpenLaszlo 的最新版本做了一些运行时改进，使它对于开发人员更具吸引力。一项改进是版本 3 引入了一种 SOLO 开发模式，使得在某些部署配置中不再需要 Laszlo Presentation Server。另一个主要的改进是客户机运行时环境。最新版本（OpenLazlo 4）正处于 beta 测试阶段，它使基于 Laszlo 的应用程序能够不带 Adobe/Macromedia Flash Player 插件运行。许多公司不愿意被限制于某种专有的插件（比如 Flash Player），他们会欢迎这一改进。
如何判断哪种产品更适合您的组织？Flex 的主要优点是可以从 Adobe/Macromedia 获得充分的产品支持，但是要为 Flex Data Services Server 的许可证付费。对于某些公司来说，付出许可证费用来换取得到充分支持的产品是值得的。Adobe Flex 2 应用程序也需要 Flash Player plug-in V9。尽管 Flex 可以创建丰富的用户体验，但是某些公司不愿意承受费用和插件限制。
OpenLaszlo 技术最初是作为商业产品发布的，但是在 2004 年 Laszlo Systems 开放了这种技术的源码，采用了 Common Public License（V1.0）许可方式。Laszlo Systems 提供支持订阅，而且因为它是一个开放源码项目，您可以选择使用免费资源支持它。对于 OpenLaszlo，费用不是大问题，但是有些组织的公司策略不允许使用开放源码软件，所以可能不能选用 OpenLaszlo。
IBM Workplace Managed Client 和 Lotus Expeditor
IBM Workplace Managed Client 和 Lotus Expeditor 都是在开放源码的 EclipseRPC 代码基上构建的。EclipseRPC 这种技术源自 Eclipse 开发工具工作台，这是由 eclipse.org 管理和控制的通用工具开发平台。如果业务需要进行无连接操作，而且可以在客户机上安装组件，那么 Workplace Managed Client 和/或 Lotus Expeditor 是构建和部署应用程序的最佳技术。
IBM Workplace Managed Client 是 IBM 的 Workplace 产品系列的一个组件。它将各种协作服务组合在一个集成框架（或者说桌面环境）中。它提供的功能包括文档管理、消息传递（包括即时消息传递）、Web 浏览、Notes® 7 的直接接口、eLearning、团队空间、Web 会议以及一个用来跟踪任务相关的线索的活动管理器。Lotus Expeditor 提供一个富客户机平台，它支持企业应用程序、事务处理、设备管理和 Web 服务。尽管选择 Workplace Managed Client 或 Lotus Expeditor 都有不少合理的理由，但是如果应用程序在本质上是协作型的，那么 Workplace Managed Client 通常是最佳选择。但是，如果应用程序在本质上是事务性的，那么通常建议选用 Lotus Expeditor。
Workplace Managed Client 和 Lotus Expeditor 都使开发人员能够创建驻留在客户机上的富客户机应用程序，可以支持无连接操作。因为应用程序驻留在客户机上，客户机可以充分利用它所在工作站的功能，可以创建出高度交互性的用户体验。Eclipse 是 Workplace Managed Client 和 Lotus Expeditor 共同的基础，它提供了一个独立于操作系统的平台，对开发人员隐藏了操作系统的细节差异，同时尽可能利用本机操作系统服务。因此，您可以开发一个 Java 代码基，它能够在 Linux™ 和 Windows™ 上运行，以后甚至能够在 Macintosh 上运行。
为了利用这种技术，需要让应用程序利用 Eclipse 插件体系结构。用户界面组件是使用 SWT（Standard Widget Toolkit）部件或 jFace 组件构建的。SWT 是一个与本机窗口系统集成的部件集和图形库，但是使用独立于操作系统的 API。jFace 是一个使用 SWT 实现的 UI 工具包，它简化了许多常见的 UI 编程任务。jFace 在 API 和实现两方面都独立于窗口系统，其设计目的是使用 SWT 而不是隐藏它。最终结果是更具交互性的用户体验，其外观和感觉与用户熟悉的其他本机操作系统应用程序相似。
最后，“由服务器管理” 这一特性使基于 Workplace Managed Client 或 Lotus Expeditor 的应用程序有别于本机 Windows 应用程序。这项关键特性消除了与客户机驻留的应用程序代码相关联的大多数（如果不是全部的话）系统管理成本。因此，部署应用程序的企业会获得服务器部署的 Java EE 应用程序的所有成本优势，同时用户能够享受操作系统特有的客户机驻留的应用程序的用户体验；对于大多数组织，这都是双赢的结果。
JavaServer Faces（JSF）是一种 Java EE 1.4 组件，最初是作为 JSR 127 开发的。这种技术的关键目标是，降低为 Java EE 应用程序开发用户界面时要求 Java 开发人员具备的技能水平。因为 JSF 是一个框架，它提供了许多开箱即用的功能；在过去，开发人员在用 JavaServer Pages（JSP）构建同样的用户界面时需要手工编写这些功能。
例如，假设您有一个大型 JDBC™ 结果集，需要将它向用户显示。JSF 框架提供了一个 DataTable 部件，可以用来显示数据。如果使用简单的 JSP 构建用户界面，您就必须管理用户与这个数据表的交互，并决定应该向用户显示哪些数据行。
通过使用 JSF DataTable，当用户点击 Next 来显示表中的后 x 行数据时，JSF 框架将会处理 Next 请求，您不必自己编写任何代码。尽管 JSF 简化了创建丰富的 HTML 用户界面的过程，但是根据设计 JSF 是一种基于服务器的技术。对后 x 行数据的请求从浏览器发送到服务器，JSF 框架代码在服务器上处理这个请求。JSF 需要一次到服务器的请求/响应往返。
为了改进基本的 JSF 部件，IBM 的 Rational® Application Developer V6 引入了 Faces Client Components。Faces Client Components 是 JavaServer Faces 技术的一种扩展，允许在客户端执行某些 JSF 框架服务。例如，如果在上面的示例中使用 DataGrid Faces Client 组件，那么后 x 行数据的显示就不需要到服务器的请求/响应往返。
对于 Rational Application Developer JSF 开发人员，使用 Faces Client Components 是自然的选择。为了使用 Faces Client Components，要创建一个 Faces JSP 页面并选择 “Basic with client-side data caching ” 作为模型。当在 Rational Application Developer 中构造用户界面时，只需从 Rational Application Developer 的工具面板中的 Faces Client Components 部分中选择适当的 UI 控件。
在 Faces Client Component 的幕后发生了许多情况。会将 JSF 控件的 JavaScript 实现下载到浏览器中，并使用符合行业标准的 Service Data Objects 在浏览器和服务器之间进行通信。但是，这一切理所当然都是对用户隐藏的；用户只会注意到，与典型的基于浏览器的应用程序相比，他的应用程序的响应速度快多了。
Ajax（异步 JavaScript 和 XML）是 Jesse James Garrett 创造的一个术语，它是指一种基于标准的技术/设计模式，用来为服务器部署的应用程序开发比浏览器更好的用户体验。Ajax 对服务器技术没有什么要求，可以处理 Java EE 应用程序、.Net 应用程序和其他应用程序。通过使用 Ajax，可以编写 JavaScript 代码来改进 HTML，创建出丰富的交互性用户体验。例如，JavaScript 可以执行本地用户输入验证，为相同的数据提供不同的视图（条形图、表格、饼图等等），或者通过浏览器的 XMLHTTPRequest 对象与应用程序的服务器组件进行异步的交互。
根据 Gartner Group 的 Hype Cycle for Emerging Technologies 2000 报告（2006 年 7 月 18 日），Ajax 已经达到了 “过度期望的顶峰”，“幻想” 已经开始成为现实了。看看书店里有那么多 Ajax 图书，就能够知道这股风潮有多么热了。按照我的观点，有三种东西帮助 Ajax 跨越了 Geoffrey Moore 指出的技术鸿沟：
- 现代浏览器。 在过去，编写 JavaScript 的开发人员必须处理 Netscape、Internet Explorer 和其他浏览器之间的许多不兼容问题。在某些情况下，甚至同一种浏览器的不同版本也有不兼容问题。尽管仍然存在一些不兼容问题，但是大多数内部网应用程序通常需要 Internet Explorer 5.5 或更高版本和/或者 Firefox 1.0 或更高版本，在这些浏览器中以前存在的大多数不兼容问题已经被纠正了。近来组成了一个开放的行业协会 OpenAjax，它的目的是解决 Ajax 的不兼容性问题，以及解决其他 Ajax 相关问题。
- Ajax 工具包。 在过去，希望使用 Ajax 的大多数开发人员实际上必须从头开始，而 Ajax 工具包现在可以替他们完成许多繁重的工作。工具包提供了各种预制的基于 JavaScript 的用户界面控件（部件），让开发人员可以轻松地创建基于 Ajax 的用户体验。工具包通常还提供更高级的抽象，从而对开发人员隐藏前面提到的浏览器不兼容问题。
- 工具。 直到最近，大多数 JavaScript 开发人员实际上没有开发工具来帮助简化开发和调试。从 Firefox 浏览器发布开始，它就为 Ajax 开发人员提供了一些有用的插件，而且 IBM 最近在 Ajax Toolkit Framework 中集成了一系列有用的技术来帮助进行 Ajax 开发。ATF（Ajax Toolkit Framework）可以从 Apache 站点免费下载，它提供一个基于 Eclipse 的 Ajax 开发环境。ATF 提供的工具包括 JavaScript 语法敏感的编辑器、JavaScript 控制台和 XMLHTTPRequest 对象查看器。ATF 还附带三个预制的个性化组件：Dojo、Zimbra 和 Rico。
最后，按照我的观点，当 Google 发布基于 Ajax 的 Google Maps 应用程序的 beta 版本时，Ajax 真正的转折点到了。以前使用过地图 Web 站点的任何人都会很快看出 Google 地图软件的优点。非技术人员感到吃惊，想知道 Google 是怎么做到的；而知道其原理的程序员开始注意到 Ajax，并开始考虑如何使用基于 Ajax 的技术改进自己应用程序的易用性和响应性。
纯 HTML
尽管许多开发人员认为所有用户像他们自己一样，使用最新的 Firefox 浏览器并带 10 个最流行的插件，但事实是许多机器仍然使用 Netscape 3.x 或 Internet Explorer 4.x 来访问互联网。使用这种水平的浏览器可能是为了使用某一应用程序（它的源代码已经丢失了，无法修改了），或者是因为用户非常保守，他们按照 “如果没有出问题，就不必自找麻烦” 的原则来对待浏览器升级，所以仍然使用 Internet Explorer 4.0。
尽管 HTML 显然不能提供其他技术可以提供的那么丰富的用户体验，但是基于 HTML 的用户界面仍然会长期占据一定的地位。还没有其他技术能够像纯 HTML 用户界面一样让那么多用户都能够使用。因此，在未来的许多年内，许多应用程序仍然会提供这种用户界面。
总的来说，当今业界的重要方向是改进服务器提交的应用程序的用户体验。Ajax 仍然还不太成熟，但是已经有了一定的实力，而且许多企业（包括小型和大型企业）已经开始在生产中使用它。本文提到的其他技术没有得到这么大的关注，但是到目前为止还不能明确地说它们没有前途。
还存在其他用户界面技术，包括商业产品和开放源码产品（比如 Nexaweb、Backbase 和 JackBE），但是由于篇幅限制本文没有提到它们。关键一点是，这些技术都不是放之四海皆准的，所以没有任何技术对于所有场景都是最佳选择。这些技术都有各自的优点，都有其适合的场景。
那么，如何做出选择呢？对于初学者来说，如果技术选择背后的主要目标是接触尽可能多的用户，那么没有任何技术能够超越老式的 HTML。在另一个极端，如果您需要无连接操作，而且可以在用户机器上安装应用程序的组件，那么基于 EclipseRPC 的替代品之一（Workplace Managed Client 或者 Lotus Expeditor）是最佳选择。
如果需要的丰富用户体验只能通过 Flash Player 来获得，那么可能应该使用 Flex 或 OpenLaszlo。如果使用 JavaServer Faces 构建应用程序，那么使用一些 Faces Client Components 会更好。
最后，如果您的目标只是在现有的 HTML 用户界面中增加一些易用性特性，或者是提供基于标准的插件免费的丰富用户体验，那么应该考虑使用 Ajax。按照目前的舆论，Ajax 似乎成了最流行的 Web 2.0 技术选择，但是我不能肯定其他技术在成熟之后会不会取代它的地位。
选择正确技术的关键是，让应用程序的需求决定对用户体验技术的选择。尽管这个建议似乎是理所当然的，但是在许多情况下开发人员所做的正好相反，他们被时髦的技术宣传所蛊惑，做出 “技术驱动的选择”，这常常导致许多困难的实现和部署问题，从而在开发项目时导致严重的延误和问题。不要让这种情况发生在您身上。