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.

JMS Destinations can be either looked up by well-known persistent names, or created with a temporary scope. For instance, a site can create a series of poker tables that a user can choose to watch, each with unique names such as "HighStakes" or "Novice." Accordingly, "HighStakes" and "Novice" would be the public names of the JMS topic to which any client would attach. Then, any messages sent to the corresponding "HighStakes" or "Novice" JMS topics on the server would be immediately pushed to only those clients who were interested in them.

Private messages are also supported by such a mapping. In JMS, there is the concept of a temporary Destination, which is scoped to the duration of a communication session. This provides a convenient way for clients and servers to attach and detach short-term channels as necessary. If, for example, there existed a well-known public JMS Queue named "HighStakesSeatRequests" where observers could send messages to attempt to sit and play at the HighStakes table, the corresponding client JMS code might look something like this:

    ObjectMessage seatRequestMessage = myPokerSession.createObjectMessage();

    // ...
    // Fill in pertinent seat reqeuest information on the seatRequestMessage
    // ...

    Queue myPrivatePlayerQueue = myPokerSession.createTemporaryQueue();
    seatRequestMessage.setJMSReplyTo(myPrivatePlayerQueue);

    myPokerSession.send(seatRequestMessage);

In JMS terms, the temporary queue's name is not important, and is usually a generated value such as "xyz123". But by creating it and setting it as the "replyTo" field, any receivers of this message - such as the server handling the seat request - can store that temporary Queue for future direct messages to that client. Notably, the server/dealer can use this temporary queue to notify that client/player if his seat request was accepted or rejected. Securing that channel is beyond the scope of this article, but it goes without saying that security through channel name obscurity is not sufficient when critical data is being transported!

Kaazing's Enterprise Comet technology supports this API by mapping the JMS APIs to Comet transports and protocols such as Bayeux and JSON. However, the application development team gets the benefit of working against the strongly typed, yet simple, JMS standard.

A Winning Combination
Translating JMS code to Comet may not be the most obvious solution for real-time programming, but it comes with real benefits. Besides the transfer of knowledge from experienced Java EE programmers, working directly against JMS APIs allows a multitude of existing back-end messages to extend their reach into the client - and vice-versa - without forcing the client or server to undergo a mapping transformation. While JMS poker applications may not be ubiquitous, monitoring and business logic messages are. Allowing a real-time Web client to handle such messages opens up the possibility for Java Swing-based clients that talk natively to JMS to be replaced with AJAX equivalents. Or, if coexistence is preferred, an AJAX client can live alongside a Swing peer, as both will be able to communicate with the back-end business logic via JMS Destinations.

This was put to the test with our own poker application, which was largely built and tested using a simple Swing client while the AJAX client was under development. The AJAX poker application was then able to speak to the shared back end by translating the Java JMS calls to our underlying Comet support. Both client types and the server can work against the same Java Object model. Cards, players, and tables run on both tiers, but are defined and implemented once. Messages can be strongly typed, with no need to drop down to text or XML. It's a refreshing way to write a Web client.

This is only one example of how an established Java API can be integrated into AJAX client development. Due in no small part to Java's head start, the pool of Java developers vastly outnumbers those with AJAX development experience. Bridging successful Java APIs to an AJAX client is a great way to expand the pool of AJAX developers and also expand the capabilities of your applications.

Resources
   •    Comet: http://en.wikipedia.org/wiki/Comet_(programming)
   •    Java Message Service: http://java.sun.com/products/jms/
   •    Firebug: www.getfirebug.com/
   •    AJAX in ActiveMQ: http://activemq.apache.org/ajax.html
   •    Enterprise Comet: http://kaazing.com/collateral/kaazing_overview.pdf