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 . In addition to this paper and the text below, it is
strongly recommended to consult .
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. 
A further distinction can be made between what is referred
to as "Page Streaming" and "Service Streaming" :
- 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
accumulating in the browser.
- Long-lived connections will inevitably fail at
some point in time, hence a scenario to restore the connection must be
- Server and client a tightly coupled, since the
- 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
- There's more flexibility regarding the content
- 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  distinguishes a kind of
third “mode” which he calls 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
] 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 . Disadvantages of
solutions that keep HTTP connections open can be summarized as follows:
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.
Some frameworks offering push-like technologies are presented in the subsections below.
The DWR (Direct Web Remoting) project   offers a library that offers
the possibility of
gives developers the feeling that they are executing code on the
client/browser, while in fact they are using Java code on the server
is realized by DWR by mashalling data backwards and forwards, much like
conventional remoting methods as RPC, SOAP or RMI work. Since AJAX is
callback function must be provided. This callback function is activated
as the data (prepared in the Java method) has arrived, e.g. to populate
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
the default direction when remoting is initiated from the client side). On their
effectiveness and simplicity is shown with a sample chat application
Pushlets  are extensively described in the aforementioned whitepaper . On the 9th of May 2006 an AJAX library became
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 ) 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)  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
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.
that may be useful in the same way as the aforementioned DWR library. Its
“comet-support” is provided by Cometd .
 Build Your Own AJAX Web Applications, http://www.sitepoint.com/article/build-your-own-ajax-web-apps
– the next stage of AJAX,
– Whitepaper, http://www.pushlets.com/
Streaming – Ajax Patterns, http://ajaxpatterns.org/HTTP_Streaming
 Wikipedia: Comet (programming), http://en.wikipedia.org/wiki/Comet_(programming)
 DWR (Direct Web Remoting): http://getahead.ltd.uk/dwr/
 Reverse Ajax:
 Chat example using reverse AJAX, http://getahead.ltd.uk/blog/joe/2006/04/11/1144770216929.html
Send events from servlets to DHTML client browsers”, article on
 ActiveMQ, http://incubator.apache.org/activemq/ajax.html
 Exploring the Google Web Toolkit, http://www-128.ibm.com/developerworks/library/j-ajax4/index.html
Socket Hungry AJAX, http://blogs.pathf.com/agileajax/2006/05/comet_socket_hu.html
10:49PM Nov 27, 2006
by Zeger Hendrikse in Java & J2EE |