The Dojo event system delivers the messages to the locally registered subscribers in the page. In this case Microsoft's stock hasn't been displayed because we didn't subscribe to /cometd/stocks/MSFT locally. Notably, if we changed the cometd subscription from /stocks to /stocks/ORCL and /stocks/SUNW then the observed behavior would be the same, but the /stocks/MSFT message would be filtered at the server, not locally at the browser.

The Internal Process
The Grizzly Comet implementation provides a CometEngine that's used to create a CometContext to which clients can register a handler. The handler is responsible for initiating the response and notifying each client about new messages that match the client's channel subscriptions. All handlers registered to the same CometContext will be simultaneously notified when a new event is delivered to the CometContext.

In our trading application, all Bayeux requests go to a BayeuxServlet at /bayeux in a Web application with context root /comet-war.

1.  Initial Request
This is a regular request to have the page rendered in the Web client, HTML, and Dojo Toolkit JavaScript including Bayeux protocol support.

2.  Bayeux Handshake Request
In our trading application Bayeux lets us create one channel per stock.

We're still only using one HTTP connection and we can use Bayeux to listen for events targeting a particular area of our application ­ in this case a stock. If we didn't have Bayeux we'd either have to invent our own publish and subscribe protocol, or else go back to polling the server because the browser connection limitations would prevent us from having more than two open HTTP connections to get the Comet notifications.

Request URI = /comet-war/bayeux
Request Payload = handshake message

The Bayeux handshake request sends a message to the /meta/handshake channel to indicate possible connection types and gets a response from the server indicating supported connection types, their recommended configuration, and a client identifier that's used for subsequent communication with the BayeuxServlet. In this case we use an iframe connection type.

3.  Bayeux Connect Request
Since we're using an ARP server each request will register a key containing information about the request. This will let the ARP release resources by releasing threads currently not used.

Request URI = /comet-war/bayeux
Request Payload = connect message

It sends a message to /meta/connect channel to begin the long-lived Comet request. Using Grizzly APIs from within the BayeuxServlet, the connect request causes the client-specific CometHandler to be registered with this trading application's CometContext.

If the server-side CometHandler times out while the trading application is still active, the client sends a Bayeux reconnect request to establish a new long-lived Comet notification request.

4.  Bayeux Subscribe Request
In our application we subscribe to the /stocks channel to get browser notifications for all stocks.

Request URI = /comet-war/bayeux
Request Payload = subscribe message

The Bayeux subscribe request sends a message to the /meta/subscribe channel, subscribing the client to the /stocks channel. Using Grizzly APIs from within the BayeuxServlet, each subscribe request causes the list of per-client subscriptions to be updated for this CometContext. If the long-lived connect request is still open then this subscribe request is sent to the server using the remaining available browser connection.

5.  ORCL Stock Price Changes
The Oracle stock price changes and a message is published to the /stocks/ORCL Bayeux channel with an application-defined structure, e.g., { Œname':'ORCL', Œprice': 19.75 }.

Using Grizzly, we get a CometContext for this application and send a message including channel name. All CometHandlers registered for this CometContext will get this message, but only those subscribed to the /stocks/ORCL or /stocks channel will actually propagate the message to the browser. If the long-lived connect request is still open then this unsubscribe request is sent to the server using the remaining available browser connection.

6.  Bayeux Unsubscribe Request
There's also a way to unsubscribe from channels and with a more sophisticated trading application the end user would be able to unsubscribe from getting updates for a stock, for example, Sun Microsystems (SUNW).

Request URI = /comet-war/bayeux
Request Payload = unsubscribe message

A message would be sent to the /meta/unsubscribe channel, to unsubscribe from /stocks/SUNW channel. Using Grizzly APIs from within the BayeuxServlet, the unsubscribe request updates the list of subscribed channels for this client on this CometContext.

Conclusion
Enterprise Comet is definitely the real deal. There's still work to be done before we have a complete Enterprise solution for developing message-driven Web 2.0 applications, but with the techniques and technologies above we've made a good start. Not only that, but the Dojo Toolkit also includes a rich set of DHTML widgets, and client-side Bayeux protocol support, which provides a great foundation for building Comet-based Web applications.

The major thing missing now is a way to realize Comet in the context of Java EE for technologies such as JSF, JMS, and EJB 3. More about this in our next article, which will show how to create a Comet-based JavaServer Faces component.