PG电子大奖视频

書名： DWR Java AJAX Applications
作者名： Sami Salkosuo
本章字數： 1178字
更新時間： 2021-04-25 17:37:52

Reverse AJAX

The term Reverse AJAX is used when a server is used to query and/or control a client-browser behavior. This may cause some questions because it sounds like our browsers are now vulnerable to attack while we visit the web pages of the world.

Luckily that is not the case, because it is not possible for a server to open a connection to a browser. A browser must always be the initiator of the connection. So, the question about security is actually valid, but a problem would mean that the website in question is designed and implemented for causing harm.

DWR supports three different methods to do Reverse AJAX in applications: Piggyback, Polling (by the client), and Comet (server push).

Piggyback

The piggyback method works so that whenever a server has an update to be sent to the client, it waits until the client opens a connection and requests some content from the server. When that happens, the server includes a new update with the response, and it is delivered to the client where DWR recognizes the update and acts accordingly and makes the update on the user's web page.

The Piggyback method is the default method for Reverse AJAX in DWR and it is called Passive Reverse AJAX (the other methods are called Active Reverse AJAX) and requires no configuration. For busy developers like us it is often a good enough solution (by the way, learning when to stop and when to develop "good-enough software" is one step from journeyman to master; see The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas)

A downside to Piggyback is that any update that happens on the server side may take a long time before it is visible to users. Depending on the application, this may not be a problem, but if it is, then the other two methods may be used, Polling and Comet, which are Active Reverse AJAX methods.

Using Reverse AJAX requires the use of DWR classes in the application code on the server side. DWR has a class called ScriptProxy that is used to execute JavaScript functions on the client. As an example, the following code snippet, which could be in a remote Java method, gets all the script sessions (in essence, HTTP sessions but for scripts) for a given page, mainpage.jsp, and then adds a function call that gets called in all the clients that are known to the server and have the mainpage.jsp open.

Collection<ScriptSession> sessions = serverContext.getScriptSessionsByPage(contextPath + "/mainpage.jsp"); ScriptProxy proxy = new ScriptProxy(sessions);
proxy.addFunctionCall("newMessage",newMessage);

On the mainpage.jsp, we would have the following function, newMessage, that updates some field in the web page.

function newMessage(newMessageParam)
{
elementToBeUpdated=document.getElementById("messageArea");
elementToBeUpdated.innerHTML=newMessageParam;
}

No configuration is needed when using Reverse AJAX using the Piggyback method. It is enabled by default in DWR. When using Piggyback, clients receive updates after they make an AJAX (DWR) request to the server application. DWR then sends all updates (from Reverse AJAX methods) together with the actual response to the client where DWR updates the web page (as in the previous example).

Polling

Polling is a "no-brainer" way to do Reverse AJAX, although it really isn't reverse since DWR periodically polls the server if there are any events on the server side of the application that require updates to the web page.

This method may be good in some cases, especially when there is no issue about extra load on the network and the server that polling causes or when updates to a client do not need to be (near) real-time as in Comet.

When we use the Polling method for Reverse AJAX the code is the same as in the sample code in the Piggyback section. Only the configuration needs to be changed. In order to use Polling we need to configure DWR to Active Reverse AJAX. This is done by adding the following init parameter to the DWR servlet in the web.xml file.

<init-param>
<param-name>activeReverseAjaxEnabled</param-name>
<param-value>true</param-value>
</init-param>

We also need to enable web pages for Reverse AJAX. This is done by adding the following line to a web page that we are using to receive Reverse AJAX requests from the server.

dwr.engine.setActiveReverseAjax(true);

The above configuration is actually all that we need for using the Comet method, which can be seen in the following section. For the Polling method, we need an additional init parameter in the web.xml file:

<init-param>
<param-name>org.directwebremoting.extend.ServerLoadMonitor </param- name>
<param-value>org.directwebremoting.impl.PollingServerLoadMonitor </param-value>
</init-param>

There is also the optional init parameter for specifying the poll interval. The default interval is 5 seconds, and it can be changed with the following init parameter.

<init-param>
<param-name>disconnectedTime</param-name>
<param-value>60000</param-value>
</init-param>

Comet

Comet, known to some as long-lived HTTP, is a very recent term (used first by Alex Russell in March 2006 http://alex.dojotoolkit.org/?p=545) for a server push method, where the browser opens the connection and it is kept open so that the server can push updates to the browser when needed, and the latency for updates is very low. The following figure shows how Comet compares to the normal AJAX model:

As we can see from the figure, Comet enables the server to send updates in response to the events, almost in real time, and there is no need to wait for the user to open a connection or to use Polling.

As mentioned in the previous section, Comet requires only the enabling of Active Reverse AJAX in the init parameter and the enabling of Reverse AJAX in the web page. Active Reverse AJAX using Comet has two modes: Full Streaming Mode (default in DWR 2.0.3 and earlier versions) and Early Closing Mode (default in DWR 2.0.4 and later versions).

The Full Streaming Mode has the fastest response time and it enables near real-time responses to the client when an event occurs on the server. In this mode, every 60 seconds, DWR checks whether the browser is active or not by closing the connection and reopening it. Early Closing Mode on the other hand causes DWR to close the connection when browser receives the output and then to reopen it. For Early Closing Mode, there is the init parameter called maxWaitAfterWrite and its value is the time in milliseconds to wait before closing the connection (and reopening it) after receiving input from the server.

There are a couple of issues that should be remembered while using Comet in DWR applications, especially for applications that have a large number of users. As clients keep the connections open to the server, it is possible that the server resources are consumed for connections and their threads. This increases the infrastructure requirements for the DWR application unnecessarily. The solution is to use the maxWaitAfterWrite init parameter and tweak it to an appropriate value. Other solutions are to use Polling or Passive Reverse AJAX.

In all the three methods, Piggyback, Polling, and Comet, DWR shows its strengths because we don't really have to know the implementation details of Reverse AJAX. DWR handles them behind the scenes and hides the details of Comet and the Polling methods, and we can use any of the three methods by just configuring DWR in the correct manner.

官术网_书友最值得收藏!

DWR Java AJAX Applications

Reverse AJAX

Piggyback

Polling

Comet