JavaOne 2008 / Day 2 (Part 2)
At the end of the 2nd day of JavaOne 2008, I attended 3 BOF sessions in a row about [tag]Comet[/tag]:
- Comet: The Rise of Highly Interactive Web Sites (by Alex Russell and Joe Walker)
- Writing Real-Time Web Applications, Using Google Web Toolkit and Comet (by Jean-François Arcand and Alexandre Gomes)
- Using Comet to Create a Two-Player Web Game (by Jean-François Arcand and Jim Driscoll)
They were all very good presentations. I was supposed to attend a session about SOA for the last time slot but after the second one I decided to follow the topic and I’m glad I did it.
What is Comet?
Do you remember the terms [tag]HTTP Push[/tag], [tag]HTTP Streaming[/tag], [tag]Pushlets[/tag]? The idea behind Comet is the same and its name is coined in 2006. You can still here [tag]AJAX Push[/tag] or [tag]Reverse AJAX[/tag], though, to refer to the same user-interaction model.
Comet is a technology that enables web clients and web servers to communicate asynchronously, allowing real-time operations and functions previously unheard of with traditional web applications to approach the capabilities of desktop applications. It allows the creation of event-driven Web applications.
Where, traditional AJAX uses continuous polling to detect new information on the server, Comet uses long-lived HTTP connections between the client and the server.
Let’s see a practical example. Go to Google Docs. Create a new SpreadSheet. Give it a name (Using my incredibly developed imagination I called it “test”), save it and close it.
Then open two copies of the same stylesheet in two different tabs or windows. Two separate windows are better because you can resize them and put them side by side so that you can see the changes in both without switching back and forth.
You’ll see that the second copy of the stylesheet contains a side frame:
This frame contains the name of the second user who has the same stylesheet open. The small square next to the name is important. That’s the color assigned to the user and to his/her actions.
Go back to the first copy and click on a cell other than the first one, which should be pre-selected:
In the example above, I clicked on the cell A3. It is indicated with a blue frame. The first cell is now shown with a green frame. This is the cell selected by the second copy/user (If you hover over the green cell, it’s going to tell you who is the owner). If you look at the other window, you’ll see that the selection colors are inverted to indicate the opposite ownership:
Let’s type “hello” in the selected cell of the first copy. As soon as you start to type, the cell is locked in the second copy:
And when you finish typing, as soon as you hit <Enter>, you’ll see the new data displayed in the second copy as well:
Just for fun, open another copy of the test stylesheet and select the cell B3. The current user’s color is always blue. And you can also see the other users with green and orange cells.
My goal was not to turn this blog entry into a Google Docs demo. I just wanted to show you a very popular rich Web application that had been using Comet.
Comet is a better interaction model compared to [tag]AJAX with Polling[/tag], which introduces an unnecessary overhead by polling constantly even when the server doesn’t have anything to say. Therefore, instead of constantly polling for potential events, Comet applications use a persistent HTTP connection between the server and the client. I can hear you thinking “What about firewalls? Proxies? Long lived connections are not good“. That’s the reason why there are two strategies to implement Comet:
- Streaming: If you use streaming Comet, your browser will open a persistent connection to the server to receive Comet events. When there’s a new event, the server will push more data to your browser using the already open connection. Obviously there are a few dangers with this approach. Firewalls may drop the long lived idle connections. Furthermore, proxies may use a buffer that they flush when the connections are closed. Therefore, if the persistent connection is never closed, the event data sent by the server may remain in the proxy’s buffer until the end of the connection or until there’s enough data to trigger a flush. That’s the reason why it’s more realistic to use the second strategy.
- Long polling: As the name suggests, this approach uses polling however a smarter version. It keeps the polling connection open until there’s data sent by the server or a timeout is reached or the connection is dropped. As soon as the connection is closed, the client opens a new one waiting for the next event or timeout (or broken connection).
Earlier versions of Safari (1KB) and Internet Explorer (256B) used an internal buffer to incrementally render a page, which may cause trouble for applications using Comet on these browsers.
Another limitation comes from the current Java Servlet specification and implementations. I think only Glassfish (v2 and v3) has out-of-the-box support for Comet. Jetty and Tomcat needs to be hacked in order to work. But the good news is Java Servlet 3.0 specification has “Async and Comet support”:
- Non-blocking input
- Non-blocking output
- Delay request handling
- Delay response close
- Blocking/non-blocking notification
I’m going to talk about the new Servlet spec in a later blog entry as one of my later sessions is about Java Servlet 3.0.
Two servers were mentioned during the BOF sessions that I attended: [tag]Cometd[/tag] and [tag]Grizzly[/tag].
Cometd is a scalable HTTP-based event routing bus.
Originally developed as part of [tag]GlassFish[/tag], Grizzly is a standalone project. It is a HTTP listener and it uses Java’s NIO technology. It constitutes a foundation to implement any type of scalable multi-threaded server.
In the second session, Jean-François Arcand and Alexandre Gomes explained how to create applications using [tag]GWT[/tag] (Google Web Toolkit) and Comet. I’m not sure whether the code of this example is online somewhere. Please drop me a line if you know the link!
GWT is my favorite RIA framework. I’ve been waiting for GWT 1.5 for a while, which is going to include some of the missing Java 5 features. I’m going to talk about GWT in a later blog entry as I’m attending a session entitled “What’s New in Ajax?” on Friday.
And in the third BOF session, the speakers went though a Tic-Tac-Toe example written with just 200 lines of Java code. You can find the source code in this blog entry of Jim Driscoll’s.
– Yagiz Erkan -
JavaOne 2008: Java + You
JavaOne 2008: Opening General Session
JavaOne 2008: Java SE 6, Java SE 7, SOA, SCA and Performance
JavaOne 2008: SOA and Performance
JavaOne 2008: SOA, SCA, REST and Comet Discussed
JavaOne 2008: Top 10 Patterns of Scalability
JavaOne 2008: Java Servlet 3.0