The Web That is Instantly On, and Always On

Kaazing Journal

Subscribe to Kaazing Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Kaazing Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Kaazing Authors: Jason Bloomberg, Kaazing Blog, Jnan Dash, Jeremy Geelan, Stacy Gorkoff

Related Topics: RIA Developer's Journal, Kaazing Journal

RIA & Ajax: Article

Enterprise Comet: Awaken the Grizzly!

The real deal

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.


More Stories By Kaazing Blog

Kaazing is helping define the future of the event-driven enterprise by accelerating the Web for the Internet of Things.

More Stories By John Fallows

John brings to Kaazing his 17 years’ experience in technology development and software design, and is considered a pioneer in the field of rich and highly interactive user interfaces. As CTO he formulates Kaazing Corporation’s vision of enabling mobile users, marketplaces and machines to connect and communicate in real-time, more reliably and at unprecedented scale. He defines the architecture of the Kaazing product suite and oversees its development. Prior to co-founding Kaazing, John served as Architect for Brane Corporation, a startup company based in Redwood City, California. Before joining Brane, he was a Consulting Member of Technical Staff for Server Technologies at Oracle Corporation. During his last five years at Oracle, he focused on designing, developing, and evolving Oracle ADF Faces to fully integrate Ajax technologies. Originally from Northern Ireland, he received his MA in Computer Science from Cambridge University in the United Kingdom and has written several articles for leading IT magazines such as Java Developer’s Journal, AjaxWorld Magazine, and JavaMagazine (DE), and is a popular speaker at international conferences. He is co-author of the bestselling book Pro JSF and Ajax: Building Rich Internet Components (Apress).

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.