Ajax 使用 Jetty 和 DWR 编写可扩展的 Comet 应用程序-JAVA.pdfVIP

面向 Java 开发人员的 Ajax: 使用 Jetty 和 Direct Web Remoting 编写可扩展的 Comet 应用程序 使用 Continuations 和 Reverse Ajax 创建事件驱动 Web 应用 程序 级别：中级 Philip McCarthy ( mailto:philmccarthy@?subject= 使用 Jetty 和 Direct Web Remoting 编写可扩展的 Comet 应用程序 ), Java 开发顾问, Independent 2007 年 8 02 日 受异步服务器端事件驱动的 Ajax 应用程序实现较为困难，并且难于扩展。Philip McCarthy 在其广受欢迎的 系列文章 中介绍了一种行之有效的方法：结合使用 Comet 模式（将数据推到客户机）和 Jetty 6 的 Continuations API （将 Comet 应用程序 扩展到大量客户机中）。您可以方便地在 Direct Web Remoting (DWR) 2 中将 Comet 和 Continuations 与 Reverse Ajax 技术结合使用。 作为一种广泛使用的 Web 应用程序开发技术，Ajax 牢固确立了自己的地位，随之而来的是一些通用 Ajax 使用模式。例如，Ajax 经常用于对用户输入作出响应，然后使用从服务器获得的新数据修改页面 的部分内容。但是，有时 Web 应用程序的用户界面需要进行更新以响应服务器端发生的异步事件，而 不需要用户操作 —— 例如，显示到达 Ajax 聊天应用程序的新消息，或者在文本编辑器中显示来自另一 个用户的改变。由于只能由浏览器建立 Web 浏览器和服务器之间的 HTTP 连接，服务器无法在改动 发生时将变化 “推送” 给浏览器。 Ajax 应用程序可以使用两种基本的方法解决这一问题：一种方法是浏览器每隔若干秒时间向服务器发出 轮询以进行更新，另一种方法是服务器始终打开与浏览器的连接并在数据可用时发送给浏览器。长期连 接技术被称为 Comet （请参阅 参考资料）。本文将展示如何结合使用 Jetty servlet 引擎和 DWR 简捷有效地实现一个 Comet Web 应用程序。 为什么使用 Comet ？ 轮询方法的主要缺点是：当扩展到更多客户机时，将生成大量的通信量。每个客户机必须定期访问服务 器以检查更新，这为服务器资源添加了更多负荷。最坏的一种情况是对不频繁发生更新的应用程序使用 轮询，例如一种 Ajax 邮件 Inbox。在这种情况下，相当数量的客户机轮询是没有必要的，服务器对这 些轮询的回答只会是 “没有产生新数据”。虽然可以通过增加轮询的时间间隔来减轻服务器负荷，但是这 种方法会产生不良后果，即延迟客户机对服务器事件的感知。当然，很多应用程序可以实现某种权衡， 从而获得可接受的轮询方法。 尽管如此，吸引人们使用 Comet 策略的其中一个优点是其显而易见的高效性。客户机不会像使用轮询 方法那样生成烦人的通信量，并且事件发生后可立即发布给客户机。但是保持长期连接处于打开状态也 会消耗服务器资源。当等待状态的 servlet 持有一个持久性请求时，该 servlet 会独占一个线程。这 将限制 Comet 对传统 servlet 引擎的可伸缩性，因为客户机的数量会很快超过服务器栈能有效处理 的线程数量。 Jetty 6 有何不同 Jetty 6 的目的是扩展大量同步连接，使用 Java™ 语言的非阻塞 I/O （java.nio）库并使用一个 经过优化的输出缓冲架构（参阅 参考资料）。Jetty 还为处理长期连接提供了一些技巧：该特性称为 Continuations。我将使用一个简单的 servlet 对 Continuations 进行演示，这个 servlet 将 接受请求，等待处理，然后发送响应。接下来，我将展示当客户机数量超过服务器提供的处理线程后发 生的状况。最后，我将使用 Continuations 重新实现 servlet，您将了解 Continuations 在其中 扮演的角色。 为了便于理解下面的示例，我将把 Jetty servlet 引擎限制在一个单请求处理线程。 清单 1 展示了 jetty.xml 中的相关配置。我实际上需要在 ThreadPool 使用三个线程：Jetty 服务器本身使用一个 线程，另一线程运行 HTTP 连接器，侦听到来的请求。第三个线程执行 servle