Reverse AJAX

    当一个服务器被用来查询/控制客户端浏览器行为时就用到 Reverse AJAX 术语。这可能会导致一些疑问，因为这听起来在我们浏览世界上的web页面时我们的浏览器就会受到攻击。

    幸运的是，不会这样，因为不可能一个服务器可以打开一个到浏览器的连接。浏览器才是连接的发起者。

    DWR 支持 3 种方法来实现 Reverse AJAX：Piggyback、Polling（by the client）以及Comet（server push）。

1、Piggyback

    当服务器有更新需要发送给客户端时，它就会等待客户端打开一个连接从服务器获取数据。客户端的DWR就会意识到更新，并在用户的web页面上做出相应的更新。

    Piggyback 是 DWR 中 Reverse AJAX 的默认方法，它被叫做 被动Reverse AJAX（其他的叫 主动 Reverse AJAX），且不需要任何配置。

    Piggyback 的一个缺点就是 服务端的更新不能够及时地被用户看到。对于有些应用来说这不是个问题，但如果确实是个问题，那就选刚才说的其他2个方法呗，Polling 或 Comet。

    使用 Reverse AJAX，要求服务端的应用代码用到一些 DWR 类。DWR 有一个类叫 ScriptProxy 负责在客户端执行 JavaScript 函数。下面的代码片段是在从某个远程java方法中摘取的，它获取一个指定页面叫manpage.jsp 的所有 script sessions，之后添加了一个函数调用，这个函数调用会在服务器所知道的所有客户端上被调用，然后 mainpage.jsp 就被打开了。

Collection<ScriptSession> sessions = serverContext.getScriptSessionsBy

Page(contextPath + "/mainpage.jsp"); 

ScriptProxy proxy = new ScriptProxy(sessions);

proxy.addFunctionCall("newMessage",newMessage);

    在 manpage.jsp 中，有一个叫 newMessage 的函数，它会更新页面上的一些字段。

function newMessage(newMessageParam) {

    elementToBeUpdated=document.getElementById("messageArea");

    elementToBeUpdated.innerHTML=newMessageParam;

}

2、Polling

    Polling 就是一个 “没有脑子” 的实现 Reverse AJAX 的办法，它真的不是 reverse，因为DWR会周期性地轮询服务器。

    这种方式在一些情形中是适用的，特别是当对网络以及服务器的额外负载觉得不是个问题时或者对数据的更新实时性要求不高时。

    当用 Polling 方式来实现 Reverse AJAX 时，代码和前面的 Piggyback 章节是一样的。只是要修改一下配置。为了使用 Polling，就要向 web.xml 中的 DWR servlet 添加一个 init 参数：

<init-param>

    <param-name>activeReverseAjaxEnabled</param-name>

    <param-value>true</param-value>

</init-param>

    还要在 web 页面中添加下面的这行代码。这个 web 页面用于接收来自服务器的 Reverse AJAX 请求。

dwr.engine.setActiveReverseAjax(true);

    上面的配置实际上就是 Comet 方法所需要做的所有配置了。对于 Polling 方法，还需要一个额外的 init 参数。

<init-param>

    <param-name>org.directwebremoting.extend.ServerLoadMonitor</param- name>

    <param-value>org.directwebremoting.impl.PollingServerLoadMonitor</param-value>

</init-param>

    还有一个可选的参数用于设定 poll interval，默认是5秒。

<init-param>

  <param-name>disconnectedTime</param-name>

  <param-value>60000</param-value>

</init-param>

3、Comet

    Comet，对于一些人来说，也叫 long-live HTTP，是一个比较新的术语，就是用于 server push，浏览器会打开一个连接，这个连接会保持开着的状态，这样当需要的时候，服务器就可以推送更新给浏览器，延迟就非常低。

    使用 Comet 的 Active Reverse AJAX 有 2 种模式： Full Streaming Mode（ DWR 2.0.3 以及早期版本默认就是这个），以及 Early Closing Mode（DWR 2.0.4 以及后续版本默认就是这个）

    Full Streaming Mode 拥有最快的响应时间，几乎就是实时响应，当一个事件在服务器上发生时。在该模式下，每 60 秒，DWR 就会检查 浏览器是否是活跃的。另一方面，Early Cloing Mode 会导致 DWR 关闭连接，当浏览器接收到输出，之后会重新打开它。对于 Early Closing Mode，有一个 init 参数叫 maxWaitAfterWrite 它的值是毫秒，在接收到服务器的输入后并等待这个秒数后就会关闭连接，然后会重新打开它。

    在 DWR 应用中使用 Comet 有2个问题应当要考虑一下，特别是当一个应用拥有大量用户时。因为客户端保持着到服务器的连接，很可能服务器资源就会被连接和它们的线程所消耗殆尽。解决方案就是将 maxWaitAfterWrite 这个 init 参数调整到一个合理值。其他的解决方案就是用 Polling 或 Passive Reverse AJAX。

    在所有的这3个方法中，DWR 显示出了它的强项，因为我们都不需要去知道 Reverse Ajax 的实现细节。