Ajax for Java developers:

Sky-Tiger

Listing 12. web.xml configuration for DwrServlet

               
<servlet>
   <servlet-name>dwr-invoker</servlet-name>
   <servlet-class>
      org.directwebremoting.servlet.DwrServlet
   </servlet-class>
   <init-param>
      <param-name>activeReverseAjaxEnabled</param-name>
      <param-value>true</param-value>
   </init-param>
   <init-param>
      <param-name>initApplicationScopeCreatorsAtStartup</param-name>
      <param-value>true</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
</servlet>


The first servlet init-param, activeReverseAjaxEnabled, activates polling and Comet functionality. The second, initApplicationScopeCreatorsAtStartup, tells DWR to initialize the ReverseAjaxTracker at application startup time. This overrides the usual behaviour of lazy initialization when the first request on a bean is made -- necessary in this case, because the client never does actively call a method on the ReverseAjaxTracker.

Finally, I need to implement the client-side JavaScript function invoked from DWR. The callback -- updateCoordinate() -- is passed a JSON representation of a GpsCoord Java bean, auto-serialized by DWR's BeanConverter. The function just extracts the longitude and latitude fields from the coordinate and appends them to a list via Document Object Model (DOM) calls. This is shown in Listing 13, along with my page's onload function. The onload contains a call to dwr.engine.setActiveReverseAjax(true), which tells DWR to open a persistent connection to the server and await callbacks.

Sky-Tiger

Listing 13. Client-side implementation of trivial Reverse Ajax GPS tracker

               
window.onload = function() {
  dwr.engine.setActiveReverseAjax(true);
}

function updateCoordinate(coord) {
  if (coord) {
    var li = document.createElement("li");
    li.appendChild(document.createTextNode(
            coord.longitude + ", " + coord.latitude)
    );
    document.getElementById("coords").appendChild(li);
  }
}
Now I can point my browser to the tracker page, and DWR will begin pushing coordinate data to the client as it is generated. This implementation simply outputs a list of the generated coordinates, as shown in Figure 2:

Sky-Tiger

Simple Web page listing generated coordinates

That's how simple it is to create an event-driven Ajax application using Reverse Ajax. And remember, thanks to DWR's exploitation of Jetty Continuations, no threads are tied up on the server while the client is waiting for a new event to arrive.

From here, it's easy to integrate a map widget from the likes of Yahoo! or Google. By changing the client-side callback, coordinates can simply be passed to the map API, instead of appended directly onto the page. Figure 3 shows the DWR Reverse Ajax GPS tracker plotting the random walk on such a mapping component:

Sky-Tiger

Figure 3. ReverseAjaxTracker with a map UI
Map showing path tracing generated coordinates

Back to top

Conclusions

You've now seen how Jetty Continuations combined with Comet can provide an efficient, scalable solution for event-driven Ajax applications. I haven't given any figures for the scalability of Continuations because performance in a real-world application depends on so many variables. Server hardware, choice of operating system, JVM implementation, Jetty configuration, and indeed your Web application's design and traffic profile all affect the performance of Jetty's Continuations under load. However, Greg Wilkins of Webtide (the main Jetty developers) has published a white paper on Jetty 6 that compares the performance of a Comet application with and without Continuations, handling 10,000 concurrent requests (see Resources). In Greg's tests, using Continuations cuts thread consumption, and concomitantly stack memory consumption, by a factor of more than 10.

You've also seen how easy it is to implement an event-driven Ajax application using DWR's Reverse Ajax technology. Not only does DWR save you much client- and server-side coding, but Reverse Ajax also abstracts the whole server-push mechanism away from your code. You can switch freely among the Comet, polling, or even piggyback methods, simply by altering DWR's configuration. You're free to experiment and find the best-performing strategy for your application, without any impact on your code.

If you'd like to experiment with your own Reverse Ajax applications, a great way to learn more is to download and examine the code of the DWR demos (part of the DWR source-code distribution, see Resources). The sample code used in this article is also available (see Download) if you'd like to run the examples for yourself.