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