Technology weblog

Monday Nov 27, 2006

Pushing AJAX


In this post some approaches to streaming data for web applications are presented. Just van den Broecke devoted a paper on this subject, the Pushlets white paper [3]. In addition to this paper and the text below, it is strongly recommended to consult [4].

Comet - pushing data to the browser

The term Comet was first coined in a posting by Alex Russell. Comet is a push-like technology that makes use of HTTP connections that remain open: an HTTP/1.1 client may expect a connection to remain open. This concept is concisely introduced as follows:

Basically the browser makes a request of the servers, but the server keeps the socket open over a long period of time.
[Comet applications] all use long-lived HTTP connections to reduce the latency with which messages are passed to the server. In essence, they do not poll the server occasionally. Instead the server has an open line of communication with which it can push data to the client. [2]

A further distinction can be made between what is referred to as "Page Streaming" and "Service Streaming" [4]:

  • Page Streaming: the HTTP connection associated with the initial page load remains open, after the server flushed the initial page content to the client. Characteristics of page streaming are:
    • The server proceeds to alter the initial page contents over time by outputting embedded scripts that manipulate the DOM. The browser is still officially wrting the initial page out, so when it encounters a complete <script> tag, it will execute the script immediately. How can the browser then in turn initiate communication when the connection is in a perpetual response state? Answer: This can easily be accomplished with an XMLHttpRequest Call or an IFrame Call.
    • Page streaming works on both Firefox and IE.
    • Some disadvantages
      • For long connections, JavaScript will be accumulating in the browser.
      • Long-lived connections will inevitably fail at some point in time, hence a scenario to restore the connection must be implemented
      • Server and client a tightly coupled, since the server (servlet) has to output JavaScript that manipulates the DOM.
  • Service streaming: streaming is implemented using XMLHttpRequest Call. Here, the XMLHttpRequest connection is long-lived, as opposed to the initial page load. Characteristics of service streaming are:
    • There's more flexibility regarding the content (i.e. content is not restricted to JavaScript) and duration (and frequency) of connections.
    • Service streaming has portability issues: it works on Firefox, but IE suppresses the response until it is complete.
    • The output can no longer be HTML script tags, because the web browser wouldn't automatically execute them, so both a polling and a parsing mechanism are needed, the latter parsing the responseText (that keeps growing in time because once flushed, the server cannot take back outdated output).

In addition, Just van den Broecke [3] distinguishes a kind of third “mode” which he calls pulling:

  • Pulling
    "is basically like fishing: request is held until data becomes available or a timeout. The request is re-issued after a random (configurable) time."
Pulling is particularly useful in scenarios where periodic updates are needed. For more information, the reader is referred to [1], [2] and [5].


One of the things that made HTTP based applications scalable was that they made use of small, stateless requests. This meant you could handle requests from an order of magnitude or more users than a comparable stateful application [13]. Disadvantages of solutions that keep HTTP connections open can be summarized as follows:

  • wasteful in terms of resources such as sockets and threads.
  • likely to stress stateful firewalls, load balancers, etc. Sometimes, a proxy sitting somewhere between server and browser will buffer responses, an unfortunate optimisation that prevents real-time data from flowing into the browser.
  • may break when scaling up to a large client base.
Scaling issues are being addressed by making modifications on the application server software (like Apache and Jetty Continuation), which conserve resources like threads and make use of IO multiplexing. However, for most major application servers such as WebSphere such type of solutions are not (yet) available.


Available frameworks

Some frameworks offering push-like technologies are presented in the subsections below.


The DWR (Direct Web Remoting) project [6] [7] offers a library that offers the possibility of invoking methods on Java objects via JavaScript functions on the browser. This gives developers the feeling that they are executing code on the client/browser, while in fact they are using Java code on the server side. This is realized by DWR by mashalling data backwards and forwards, much like more conventional remoting methods as RPC, SOAP or RMI work. Since AJAX is asynchronous by nature, a Javascript callback function must be provided. This callback function is activated as soon as the data (prepared in the Java method) has arrived, e.g. to populate a list with data. The DWR library also offers a Comet-like push technology, which is called "reverse AJAX". This name is self-explanatory once one realizes that it is enabled by Java code on the server calling JavaScript code on the client side (as opposed to the default direction when remoting is initiated from the client side). On their webpage, its effectiveness and simplicity is shown with a sample chat application [8].


Pushlets [9] are extensively described in the aforementioned whitepaper [3]. On the 9th of May 2006 an AJAX library became available for pushlets. This release includes a sample AJAX Javascript client. By inspection of this JavaScript client, it turns out that it is based on the aforementioned service streaming (using the XmlHttpRequest object), using a fall-back scenario for Internet Explorer by setting out a new request as soon as data has arrived. This gives the “feeling” that data is pushed to the client.

Note that a library (JAR file) has been included for rich client applications as well, making the same “pushed data” mechanism available for these applications too.


ActiveMQ is best introduced by quoting the website itself:

“Apache ActiveMQ is a fast open source JMS 1.1 Message Fabric which supports clustering, peer networks, discovery, TCP, SSL, multicast, persistence, XA and integrates seamlessly into J2EE 1.4 containers, light weight containers and any Java Virtual Machine together with having a host of Cross Language Clients”


Although the messaging fabric of ApacheMQ is irrelevant to this discussion, its AJAX support classes (consult [10]) are:

“Ajax support in ActiveMQ […] allows any web capable device to send or receive messages over JMS.”


Pushing data to the client is established by registering a listener with the MessageListenerServlet. As it has been argued at the beginning of this post, it is not possible to send a message directly to the client: the client must perform a type of poll for messages. To avoid the load versus latency tradeoff that is inherent to any kind of polling mechanism, ActiveMQ uses a much more efficient so-called waiting poll mechanism.

To employ this mechanism, an ActiveMQ AjaxServlet needs to be installed with the portlet to support JMS over Ajax. The Ajax featues of AMQ are provided on the client side by the ams.js script.


The GWT (Google Web Toolkit) [11] takes a rather unusual approach where it comes to developing webapplications: GWT presents the programmer with a Java API, with which rich client like applications are developed quite similar to the development process used in AWT, Swing or RCP based environments. Thereafter, such an application is converted to a webapplication with the included compiler, which generates JavaScript. To this extent, a library of widgets is available, but tailor-made widgets may be designed too.

Howerver, in order to provide streaming data with GWT, a custom streaming widget would have to be developed, which is likely to be quite labour intensive.


Dojo is a JavaScript library that may be useful in the same way as the aforementioned DWR library. Its “comet-support” is provided by Cometd [12].


[1] Build Your Own AJAX Web Applications,
[2] Comet – the next stage of AJAX,
[3] Pushlets – Whitepaper,
[4] HTTP Streaming – Ajax Patterns,
[5] Wikipedia: Comet (programming),
[6] DWR (Direct Web Remoting):
[7] Reverse Ajax:
[8] Chat example using reverse AJAX,
[9] “Pushlets: Send events from servlets to DHTML client browsers”, article on JavaWorld,
[10] ActiveMQ,
[11] Exploring the Google Web Toolkit,
[12] Cometd,
[13] Comet: Socket Hungry AJAX,


Post a Comment:
Comments are closed for this entry.

Hire us