Ajax, or Asynchronous JavaScript and XML, has become a household name in the area of Web applications, this mechanism by which a browser accesses a RESTful Web service and updates its GUI without a screen refresh, has spread from its pioneering roots in on-line maps and calendars to pretty much a standard feature in most new Web applications. However, it was not until recently that a new term was coined to complement this approach, one which is now often dubbed reverse-Ajax, its name: Comet.
In order to comprehend why one would need something like reverse-Ajax – or Comet – one need just look at the nature of real-time events, such as those occurring in the stock market or in sporting matches. Let's assume you are charged with creating a Web-based application with Ajax – as in no full-screen refresh – based on one of the aforementioned areas, what time span would you use for making new asynchronous calls to your data services? Remember, you don't want users to miss any new action in the game, or worse, miss a stock quote to place their orders.
This type of design has no easy answers, if you use too long an interval users might miss out on new information, on the other hand, if you use too short an interval it will likely flood your data service with unnecessary requests. At the heart of this issue is of course the stateless nature of Web applications, but there is one solution to this conundrum, the server notifying the client on the availability of new data, also often referred to as serverside push.
To those initiated in rich-client technologies like Flash or Java, this process – and even Ajax – might seem trite, especially since these last technologies have integrated mechanisms like remoting and streaming to deal with asynchronous requests from both client to server and vice-versa, but what Comet is all about is pulling off this last process using the same vanilla technologies as Ajax – namely JavaScript and HTML. So with that said, lets see how this design needs to be tackled.
The first thing you need to realize is that the data service on the serverside needs to be designed to hold state on behalf of browsers clients, a process that can either be very difficult or very easy, depending on the platform and language you are using. Once again, this takes us to the stateless nature of Web applications and the way a browser needs to identify itself constantly either via cookies or session IDs, or what some characterize as the Hollywood principle – "don't call us we'll call you" – referring that only a browser is equipped to make calls and never vice-versa.
This last issue takes us down the road of building an asynchronous server application, or if you prefer a fancier name, an HTTP-based event routing bus, or in other words, a latent application on the serverside able to keep track of clients wishing to receive updates, a design very much in line with the messaging systems used in enterprise systems that are based on publish/subscribe channels.
However, since this last mechanism represents a departure from the "bread and butter" approach used in most Web platforms, it is a big reason why most Comet applications today rely on either custom adapted application-servers or embeddable versions that can tackle these issues. In the particular case of Java, Jetty and Grizzly are two servers that currently have out-of-the box support for Comet-type designs, with varying support in other languages like Python and other popular Java servers like Tomcat, for what is technically known as "continuation support," a paradigm by which applications are shielded from the stateless nature of the Web. Continuation support also is a touted feature of higher-level language Web frameworks written in Smalltalk and Lisp that have this capability.
Turning our attention to the client side of things, a browser can take various routes to stay in contact with these type of server applications. Among these approaches are long-polling, dynamic script tags and inclusively a workaround using IFrames, none are standard approaches by any means, which is yet another reason why many client side Comet designs rely on the use of frameworks to abstract away incompatibilities between browser implementations – similar to Ajax – with one such framework being Dojo, which in itself now serves as both an Ajax/Comet framework.
As a matter of fact, in this latter area there is already ongoing work in standards like HTML 5 to implement and natively support Comet-type payloads via a simple tag named event-source, doing away in this case with the need of frameworks and fragmented approaches to display Comet-bound data. However, as is the case with most standard related issues, this is very much in the future and will be a reality once browser vendors get on the same page.
As far as the actual term is concerned, Comet emerged as a pun to Ajax's meaning outside IT circles as a household cleaner. But quirky name or not, Comet is serving the purpose of an umbrella name for delivering data onto browsers as it becomes available on the serverside, a technique that will surely be of the same impact and go hand in hand with what we know today as Ajax.
About the author
Daniel Rubio is an independent technology consultant with over 10 years of experience in enterprise and Web-based software. He blogs regularly on these and other software areas.
