Today, our goal is to bring the power of an event-driven Web - one that breaks away from the request-response patterns ingrained over the last 10 years - to the largest possible development community.

High Stakes Development
To that end, my peers and I built technology to bring real-time AJAX development to Java developers. Our core technology is the Chai virtual machine that allows Java bytecode to be translated down to the browser and run without any plugins or setup. Other projects such as the Google Web Toolkit (GWT), Java2Script, and Script# take a similar translation approach. Even though the focus differs, these projects share a goal of allowing developers to write AJAX applications in their familiar development environment and language, and let the framework or virtual machine generate the corresponding JavaScript. Why does this approach work so well for AJAX development?

AJAX applications generally are impressive not for what they do, but for where they do it. As amazing as it has been to see mapping tools, photo browsers, and chat clients running in a browser, these applications have been running just fine as native or Java clients for many years. There are many more skilled Java and .NET developers across the world that can write such applications in their frameworks than there are skilled AJAX developers. Although an elite few have the skills required to craft AJAX applications by hand, a much larger majority would love to apply their Java or .NET expertise to browser-based clients.

Using a translated JavaScript client rather than a hand-coded file frees the runtime code from the constraint of being human readable, thereby increasing the opportunity for optimizations.

Similarly, server-side translation allows for a single source of truth that can target and adapt to the differences in browsers. Although client-side frameworks can also do this, they can incur an overhead for executing through a runtime.

Why partition your developers across tiers? If your server team already has the knowledge of your communication protocols, let them work on both ends of the pipeline. They can implement both using the Java they already know, even if the client side is translated to JavaScript.

To demonstrate these benefits, we had approached SYS-CON Media with the idea of building a showcase application for its conference, AJAXWorld Conference & Expo, based on our translation product. We agreed that a Texas Hold'em poker game would be a great way to deliver in real-time to a conference audience. Unlike the standard stock quote ticker demos, a poker game gives users a hands-on way to see their own actions reflected in real-time across the screens of their eight competitors, and potentially hundreds of viewers. Using our translation technology, it was feasible to quickly build a poker application that would look great in the browser, even if the coding was done via Java and with our familiar tools.

Comet Rising
When you need real-time, event-driven Web applications, the clear choice is to use the technique broadly known as "Comet." Using a Comet approach implies keeping a connection open between the server and each client. This allows for a "push" style of notification, whereby the server can inform the client of events asynchronously rather than waiting for the client to poll for updates at regular intervals.

Polling - the predominant way of driving a real-time Web client for the last few years - ties up the network and the server with unnecessary status update requests. Furthermore, polling inherently introduces latency tied to the frequency of the poll; the cost of that latency might not matter in some situations, but there are quite a few applications where every second counts.

Although Comet techniques have been in practice for a while now, it is only recently that major application and Web servers have built-in support for Comet in ways that do not cripple scalability. Servers such as Glassfish, Tomcat, and Jetty allow browsers to maintain Comet connections without dedicating a thread to each client. This was a key requirement of our own poker game, as we needed the ability for tens or hundreds of viewers to observe a game table without constantly slowing the server with update requests.

Reinventing the Java Message Service
To keep each game fast and exciting, we needed to make sure that players moved within an allotted time, and that no one was able to stall the game by pausing indefinitely. In other words, we needed to make sure that the game did not depend on the standard request-response cycle, and that the server had the power to force the game forward with or without user participation. How can we bring the real-time programming model of a Comet application to a Java-to-JavaScript translation environment?

The natural solution for a real-time Java API is one that is already well established in the Java Enterprise Edition space, having been included in the standard for years: Java Message Service (JMS).

JMS is a standard set of APIs for sending messages asynchronously across distributed systems. The APIs are supported across all Java EE application servers and allow developers to share messages as plain text, maps, streams, or even full object instances. All the while, the JMS servers and clients remain loosely coupled, with no necessary knowledge of each other beyond the shared message destinations to which they send or receive predefined data types.

JMS works on a publish/subscribe model, where participants can either broadcast messages to any listener inclined to hear them (via a "Topic"), or target them to a queue where there is a single consumer (via a "Queue"). The Topics and Queues, known collectively as "Destinations," can be established by well-known names or created temporarily and discarded after use. Enterprise Java developers have been using JMS for years, and there is a wealth of documentation and familiarity with its APIs. Apache's popular ActiveMQ messaging server has already provided AJAX client libraries for bridging its JMS messages to the browser, although it is limited to using text formats for its payloads.

Consider the poker game again: each player and observer needs to be able to see public moves and events broadcast over the course of the game. On the other hand, those actually participating in the game also need private dedicated channels by which moves can be made and hidden values (i.e., player cards) can be sent to them alone. The JMS API accommodates this, as the moves of the dealer and other players can be broadcast to a public JMS Topic that all players and observers listen to, while the private cards and player moves are distributed via a set of private JMS Queues between dealer and player.