The Bayeux protocol, named for the Bayeux Tapestry with its picture of Halley's comet, provides a solution to this problem. Bayeux formalizes the exact protocol that clients should use to initiate the Comet connection and subscribe and unsubscribe from hierarchically named Bayeux channels.

/stocks
/stocks/ORCL
/stocks/MSFT
/bonds

When a message is delivered to a channel at the server, it's only published to those clients that have previously subscribed to that channel. Due to the hierarchical naming scheme, messages sent to a channel named /stocks/ORCL will also be delivered to clients subscribed to the /stocks channel.

Dojo and Bayeux
The Bayeux protocol is an effort by the Dojo Foundation to simplify the use of Comet. Bayeux development is hosted as a sibling project to the Dojo Toolkit, which already includes client-side Bayeux support in JavaScript.

OK, we might be jumping ahead here, but we feel that Bayeux is likely to become the de facto standard for Comet messaging because the Dojo Toolkit has gotten tremendous backing from the developer community and because the protocol is language-neutral. Bayeux has a pluggable transport layer so any agreed wire syntax can be used to marshal messages between the client and server, or vice versa and there are already implementations in multiple languages.

ARP and Comet Architecture
Our sample solution, the trading application, requires sophisticated integration with external business systems, such as business services updating the stock prices.

The Trading Application
Our message-driven distributed enterprise application needs an ARP solution for the Web client, so we're going to use Grizzly as our server-side ARP and Comet runtime implementation. Grizzly provides ARP support in Java and is currently snoozing under the covers of Project Glassfish, version 2. (http://glassfish.dev.java.net). For our sample application we also used the Dojo Toolkit (http://dojotoolkit.org/), which already includes client-side Bayeux support in JavaScript.

Note: When this was written, there was no server-side Bayeux protocol support in Grizzly so for this article we used our own Bayeux servlet. We intend to convert this to a Bayeux weblet and make it available for download from the Weblets Project (http://weblets.dev.java.net).

We'll use a simple UI to demonstrate the trading application's server-initiated message-delivery mechanism. The UI contains three buttons each capable of initiating a request to publish a stock price update message. The server will immediately notify all end users who subscribed to the same stock. The page source for this simple trading application is in Listing 1.

The page contains standard Dojo Toolkit initialization via the dojo.js library and imported the required Dojo packages for dojo.io.cometd and dojo.event.topic:

function setupComet() {
    cometd.init({}, "/comet-war/bayeux");
    cometd.subscribe("/stocks");
    dojo.event.topic.subscribe("/cometd/stocks/ORCL","onStockUpdate");
    dojo.event.topic.subscribe("/cometd/stocks/SUNW","onStockUpdate");
}

When the page loads, we initialize the Dojo cometd support with the URL to the BayeuxServlet, "/comet-war/bayeux." In this sample we then subscribe directly to the "/stocks" Bayeux channel, as well as the local event topics "/cometd/stocks/ORCL" and "/cometd/stocks/SUNW." These two local event topic subscriptions could easily be done by the end user after the application is launched, but for now we can treat them as default subscriptions.

Let's have a look at the three buttons; each one in the body is configured to publish an event to a specific Bayeux channel at the server:

    <button onclick="cometd.publish(Œ/stocks/ORCL',
       {Œname':'ORCL', Œprice': 19.75});" >SUNW 19.75
    </button>

When a message is published to the server on a Bayeux channel, such as "/stocks/ORCL," then it's delivered to all clients subscribed to the "/stocks/ORCL" channel or the "/stocks" channel. If a message is sent to /bonds then it's delivered to all clients subscribed to /bonds. In this example, the trading application only gets messages for /stocks. This server-side filtering ensures that unwanted messages aren't sent to clients.

When a message is delivered to a client, the Dojo event system delivers it to any locally registered subscribers in the page. By default, local event topics are named by prefixing the Bayeux channel name with "/cometd." For example, if a message is received from the server via the Bayeux channel "/stocks/ORCL" then it's published to local subscribers using the topic name "/cometd/stocks/ORCL." Local event topic subscription is shown in the setupComet() JavaScript function:

function setupComet() {
    cometd.init({}, "/comet-war/bayeux");
    cometd.subscribe("/stocks");
    dojo.event.topic.subscribe("/cometd/stocks/ORCL","onStockUpdate");
    dojo.event.topic.subscribe("/cometd/stocks/SUNW","onStockUpdate"); }

Figure 1 shows two clients running the code used in the page source sample.

In the second set of screen shots shown in Figure 2 we've clicked on all three buttons in the application running in Firefox and since we're using Comet this causes both clients to be updated with new information.

As you can see, there are only two messages displayed in each client.