GlassFish v3 Technology Preview 2 Application Server >> GlassFish v3 Application Server Developer's Guide >> Developing Applications and Application Components >> 7.  Developing Web Applications >> Using the Grizzly Comet API >> Introduction to Comet

Previous: Using the Grizzly Comet API

Introduction to Comet

Comet is a programming technique that allows a web server to send updates to clients without requiring the clients to explicitly request them.

This kind of programming technique is called server push, which means that the server pushes data to the client. The opposite style is client pull, which means that the client must pull the data from the server, usually through a user-initiated event, such as a button click.

Web applications that use the Comet technique can deliver updates to clients in a more timely manner than those that use the client-pull style while avoiding the latency that results from clients frequently polling the server.

One of the many use cases for Comet is a chat room application. When the server receives a message from one of the chat clients, it needs to send the message to the other clients without requiring them to ask for it. With Comet, the server can deliver messages to the clients as they are posted rather than expecting them to poll the server for new messages.

To accomplish this scenario, Comet applications establish long-lived HTTP connections. This kind of connection reduces the latency experienced by applications that need to periodically poll the server for updates because it relieves them from having to frequently open and close connections. By keeping a connection open, Comet applications can send data to clients at any time over a single connection.

The Grizzly Implementation of Comet

One limitation of the Comet technique is that you must use it with a web server that supports non-blocking connections in order to avoid poor performance. Non-blocking connections are those that do not need to allocate one thread for each request. If the web server were to use blocking connections then it might end up holding many thousands of threads, thereby hindering its scalability.

The GlassFish server includes the Grizzly HTTP Engine, which enables asynchronous request processing (ARP) by avoiding blocking connections. Grizzly's ARP implementation accomplishes this by using the Java NIO API.

With Java NIO, Grizzly enables greater performance and scalability by avoiding the limitations experienced by traditional web servers that must run a thread for each request. Instead, Grizzly's ARP mechanism makes efficient use of a thread pool system and also keeps the state of requests so that it can keep requests alive without holding a single thread for each of them.

Grizzly supports two different implementations of Comet:

• Grizzly Comet

• An implementation of the Bayeux protocol.

Grizzly Comet is based on the ARP and includes a set of APIs that you use from a web component to enable Comet functionality in your web application.

The Bayeaux implementation is a Grizzly implementation of Cometd, which consists of the JSON-based Bayeux message protocol, a set of Dojo libraries, and an event handler. The Grizzly implementation of Cometd consists of a servlet that you reference from your web application.

This tutorial covers the Grizzly Comet implementation only. For more information on using the Bayeux implementation, see Introducing the Cometd framework and its Bayeux protocol support in Grizzly

The Grizzly Comet API

Grizzly's support for Comet includes a small set of APIs that make it easy to add Comet functionality to your web applications. The Grizzly Comet APIs that developers will use most often are the following:

• CometContext: A Comet context, which is a shareable space to which applications subscribe in order to receive updates.

• CometEngine: The entry point to any component using Comet. Components can be servlets, JavaServer Pages^TM (JSP^TM), JavaServer Faces components, or pure Java classes.

• CometEvent: Contains the state of the CometContext object

• CometHandler: The interface an application implements to be part of one or more Comet contexts.

The way a developer would use this API in a web component is to perform the following tasks:

1. Register the context path of the application with the CometContext object:

   CometEngine cometEngine = 
   	CometEngine.getEngine();
   CometContext cometContext = 
   	cometEngine.register(contextPath) 

2. Register the CometHandler implementation with the CometContext object:

   cometContext.addCometHandler(handler)

3. Notify one or more CometHandler implementations when an event happens:

   cometContext.notify((Object)(handler))

Client Technologies to Use With Comet

In addition to creating a web component that uses the Comet APIs, you need to enable your client to accept asynchronous updates from the web component. To accomplish this, you can use JavaScript, IFrames, or a framework, such as Dojo.

An IFrame is an HTML element that allows you to include other content in an HTML page. As a result, the client can embed updated content in the IFrame without having to reload the page.

The example explained in this tutorial employs a combination of JavaScript and IFrames to allow the client to accept asynchronous updates. A servlet included in the example writes out JavaScript code to one of the IFrames. The JavaScript code contains the updated content and invokes a function in the page that updates the appropriate elements in the page with the new content.

The next section explains the two kinds of connections that you can make to the server. While you can use any of the client technologies listed in this section with either kind of connection, it is more difficult to use JavaScript with an HTTP-streaming connection.

Kinds of Comet Connections

When working with Comet, as implemented in Grizzly, you have two different ways to handle client connections to the server:

• HTTP Streaming

• long-polling

HTTP Streaming

The HTTP Streaming technique keeps a connection open indefinitely. It never closes, even after the server pushes data to the client.

In the case of HTTP streaming, the application sends a single request and receives responses as they come, re-using the same connection forever. This technique significantly reduces the network latency because the client and the server don't need to open and close the connection.

The basic life cycle of an application using HTTP-streaming is:

request --> suspend --> data available --> write response --> data available --> write response

The client makes an initial request and then suspends the request, meaning that it waits for a response. Whenever data is available, the server writes it to the response.

Long Polling

The long-polling technique is a combination of server-push and client-pull because the client needs to resume the connection after a certain amount of time or after the server pushes an update to the client.

The basic life cycle of an application using long—polling is:

request -> suspend --> data available --> write response --> resume

The client makes an initial request and then suspends the request. When an update is available, the server writes it to the response. The connection closes, and the client optionally resumes the connection.

How to Choose the Kind of Connection

If you anticipate that your web application will need to send frequent updates to the client, you should use the HTTP—streaming connection so that the client does not have to frequently reestablish a connection. If you anticipate less frequent updates, you should use the long-polling connection so that the web server does not need to keep a connection open when no updates are occurring. One caveat to using the HTTP-streaming connection is that if you are streaming through a proxy, the proxy can buffer the response from the server. So, be sure to test your application if you plan to use HTTP-streaming behind a proxy.

Next: The Hidden Example