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 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.

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.