方便 Ajax 与 Java EE 的集成（1）

look_w

Asynchronous JavaScript + XML （Ajax）是个相当新的术语（有些人说它是旧酒装新瓶），在不同的 Web 开发社区中，都引起了很大的争议，其中包括 Java EE 社区。Ajax 技术通过消除过多的 Web 页面刷新，提高了应用程序的可用性。而且 Ajax 二者通吃的技术，同时利用了客户端和服务器端代码，向 Web 用户呈现了几乎无缝的用户界面。Ajax 被鼓吹成 Web 开发复兴（或称为 Web 2.0）的一个主要推动者。
作为用心的 Java EE 开发人员，您可能已经阅读了许多关于 Ajax 的 how-to 文章，并对它会给应用程序带来的可能改进而兴奋。但是 Ajax 基于异步通信的模式要怎样才适合您的 Java EE 应用程序呢？这篇文章通过研究在 Java EE 应用程序的设计、开发、执行和测试各阶段引入 Ajax 会带来的影响，将帮助您回答这个问题。我的目的不是不鼓励使用 Ajax 或者暗示您可能遇到的问题是 Ajax 技术固有的问题。相反，我是为了帮助您规划并减轻这些问题，好让您更有效而顺利地利用 Ajax。
解决设计缺陷相当一段时间以来，Java 社区一直在努力把好的设计模式应用到与 Web 有关的应用程序开发上。其中使用最广泛的一个模式就是模型-视图-控制器（MVC）。一些开放源码框架，例如 Apache Struts，就基于这个设计模式/架构（请参阅 ）。MVC 的众多优势包括：问题隔离 和减少冗余代码。
问题隔离在整个应用程序架构中使用预先协商好的接口，从而让应用程序开发项目中的每个开发人员都专注于自己特定的角色。例如，模型层的开发人员侧重于 JDBC、企业 JavaBean（EJB）组件或者与底层数据持久技术接口的 Java 类这一类的技术。视图层开发人员侧重于 Java 服务器页面（JSP）技术、标记库和其他与表示有关的技术。控制器层隔离及协调模型和视图，把进入的请求路由到后端持久性调用，同时维护问题的清晰隔离。图 1 演示了 MVC 架构：
图 1. MVC 架构把 Ajax 引入 Java EE Web 应用程序对于问题的隔离（以及开发人员角色的隔离）是有意义的。在某些情况下，Ajax 会把大量 JavaScript 代码带回视图层（JSP）页面。表 1 描述了没有 Ajax 的视图层，还指出了需要的代码（假设控制器层由 servlet 实现，视图层由 JSP 技术实现。（在下一节  我将解释同步和异步请求的区别。）
表 1. 没有 Ajax 的 MVC：与典型的视图层序列有关的代码数量序列说明要求代码？在调用同步请求之前准备表单提交需要的脚本代码否调用异步请求由按钮或链接调用引起表单提交；DOM 元素的值自动设置到 HttpRequest（通过 GET 或 POST）。否：所需要的只是调用页面提交的途径。处理同步请求的响应在服务器端代码执行完成后，通常会向 JSP 发送回一个对象（通过 HttpRequest 或保存在 HttpSession 中）。这时，在 JSP 中可以通过 HttpRequest 或 HttpSession 访问这个对象（通过脚本或某些标记库），只需要编写极少的脚本就可以显示对象的内容。是：最少的脚本。
对比表 1 和表 2，表 2 描述了有 Ajax 的 MVC 视图层，同样假设控制层由 servlet 实现，视图层由 JSP 技术实现。
表 2. 有 Ajax 的 MVC：与典型的视图层序列有关的代码数量序列说明需要代码？在调用异步请求之前需要用 JavaScript 代码检索出 Ajax 调用需要的 DOM 元素的值。是调用异步请求需要用 JavaScript 代码创建 XMLHTTPRequest 并把（以前搜集的）DOM 元素值与之关联并发送（XMLHTTPRequest.send()）。是处理异步请求的响应在服务器端代码执行完成后，要用 JavaScript 代码得到请求（从 XML 响应流中）并把值相应地填充到适当的 DOM 元素。是
可以看出，由于使用了 Ajax，视图层的脚本编写量增加了，从而导致三个明显缺陷：

• JSP 要求大量的 JavaScript 代码。
• 这个设计破坏了角色问题的隔离。
• 设计重新带回了单一 JSP（模式 1 方法：一堆 HTML、CSS 代码、图片和脚本代码），这是一种反模式，极难阅读和维护（请参阅 ）。

有几个选项可以避免或者至少减轻这些设计缺陷：

• 设计时脑子里记着重用：不幸的是，编写特定于 Ajax 支持的代码通常很难避免。请计划和设计脚本代码，以便能够最大限度地重用它。
• 采用客户端 MVC 方法：可以合并使用客户端 MVC 方法，详见 Dave Crane 等编写的 Ajax in Action（请参阅 ）。这种方法可以促进问题的隔离，但是增加了复杂性，所以使用的时候要仔细考虑。
• 使用 Ajax 框架：存在多个开放源码的 Ajax 框架，例如 Direct Web Remoting （DWR）（请参阅 ），它们做了很好的工作，可以用最少的编码，就把 Ajax 模式集成到 Java EE 应用程序。
• 重新评估设计的正确性：实际上，Ajax 为 Web 应用程序提供了桌面应用程序的属性。如果一个 Web 应用程序中大多数客户端交互都利用 Ajax，那么这个应用程序可能最好设计成桌面应用程序。

处理开发困境在 Java Web 开发中使用 Ajax 时，重要的是完整理解同步 和异步 通信模型的区别（请参阅 ）。对异步通信模型支持的缺乏，会对客户端开发、与 Web 框架的集成、标记库的使用、IDE 的使用以及线程的行为有影响。
在同步请求/响应通信模型中，总是浏览器（与 Web 服务器、应用服务器或 Web 应用程序相对）发起请求（通过 Web 用户）。接着，Web 服务器、应用服务器或 Web 应用程序响应进入的请求。在处理同步请求/响应对期间，用户不能继续使用浏览器。
图 2 中的序列图演示了传统 Web 应用程序的同步通信模型。请注意在服务器的生命线上，来自客户机的数据提交和服务器端的处理是紧密耦合的。
图 2. 同步通信序列在异步请求/响应通信模型中，浏览器（通过 Web 用户）到 Web 服务器、应用服务器或 Web 应用程序的通信（以及反过来）是解耦的。在异步请求/响应对的处理中，Web 用户在当前异步请求被处理时还可以继续使用浏览器。一旦异步请求处理完成，异步响应就被通信（从 Web 服务器、应用服务器或 Web 应用程序）回客户机页面。典型情况下，在这个过程中，调用对 Web 用户没有影响；他们不需要等候响应。
图 3 的序列图演示了异步通信模型。请注意第一个 dataSubmission （由服务器端处理）和第一个返回的 dataSubmission，两个都用红圈圈上了。这些序列是解耦的。这个图示还强调了一个重要方面（后面将详细介绍，请参阅 ）：在这个模型中，可以发生多个提交（线程）。
图 3. 异步通信序列客户端影响在向 Web 应用程序引入 Ajax 时，开发团队需要注意几个风险，主要与生成的 HTML 页面及其与浏览器的交互方式有关。这些问题在 Chris Laffra 两部分的 Considering Ajax 系列中有详细介绍（请参阅 ）。有些需要记住的要点是：

• 可能没打开脚本功能：出于各种原因，在许多用户的浏览器上禁止了 JavaScript 支持。
• 跨浏览器支持增加了代码需求：支持多种浏览器和多个浏览器版本的应用程序，要求的脚本代码可能会增多，因为浏览器解释 DOM 对象的方式有细微的差异（所以操作这些元素的 JavaScript 代码也有差异）。
• JavaScript 不安全：在多数浏览器中，可以选择查看源代码选项，查看到与 HTML 页面关联的 JavaScript 源代码。在使用 Ajax 模式时，要确保脚本代码中实现的逻辑不是敏感逻辑。