6.7. Advanced Extensions to BlazeDS Data Push

Although BlazeDS supports data pushing through its streaming and polling channels, its readiness as an enterprise-grade data pushing solution is suspect. The commercial alternative to BlazeDS, LifeCycle Data Services (LCDS) does not suffer from this problem though. LCDS has a direct scalable connectivity option in RTMP, which is an acronym for Real Time Messaging Protocol. RTMP is a proprietary protocol that is capable of high-performance data pushing and streaming. Earlier this year, Adobe announced that it would open the RTMP specification to the community. Until that happens and subsequently an implementation for RTMP becomes available for BlazeDS, from a scalability and reliability perspective, data push options in BlazeDS look weak.

So, your choices are to either go with LCDS or bring the robust Comet and NIO options into BlazeDS's fold. Going with LCDS is a commercial decision, since the product is licensed and the license fee is not inexpensive. Going with Comet requires the creation of new endpoints and plumbing changes in the core BlazeDS message broker and its artifacts. In this section, I will explain how one can incorporate Comet and NIO into BlazeDS. First, though, let me define these terms for you.

Comet, as a term, was proposed by Alex Russell of the Dojo project (www.dojotoolkit.org) in a blog post titled "Comet: Low Latency Data for the Browser." You can access Alex's blog post on Comet at http://alex.dojotoolkit.org/2006/03/comet-low-latency-data-for-the-browser/. He used the term to connote event-driven server-initiated data pushing of streams to web applications from the server over long-lived HTTP connections. This was a distinct deviation from the traditional request-response–based interactions. It was also clearly separated from the polling-based mechanism to get frequent updates. Comet today serves as an umbrella term for all server-initiated data push options over persistent HTTP connections. A few standards like the Bayeux protocol (http://svn.cometd.org/trunk/bayeux/bayeux.html) are attempts at standardizing Comet, but we are still a long way from universal acceptance of this standard.

NIO, or Java NIO, is the new Java I/O specification that was introduced in Java 1.4. NIO introduces new functionality for enhanced performance in the areas of buffer management, scalable network and file I/O, character-set support, and regular-expression matching. Its nonblocking I/O support is extremely useful in creating persistent connections that form the truss for a successful Comet implementation. Therefore, NIO servers as an important ingredient in Comet implementations with Java-based web and application servers.

In addition, the new Servlet 3.0 specification directly adds support for persistent connections, better thread management, and asynchronous communication, to allow for Comet-like interactions in Java Servlet containers and application servers. A few open source application servers, such as Webtide Jetty and Apache Tomcat, have already started integrating these features into their new releases.

For this section, I will choose Jetty 7 as the web and application server of choice and show how Comet could be leveraged with BlazeDS in that server.

6.7.1. Comet Inclusion with BlazeDS in Jetty 7

One of the compelling reasons to choose Jetty 7 as the server is the support for "continuations" in that server. The word "continuations" in the context of Jetty implies the ability to suspend an ongoing request processing and resume it at a later time. The process could resume either after a timeout ends or on a notification.

In Jetty 7, calling ContinuationSupport.getContinuation(HttpServletRequest request, Object lock) returns a reference to a Continuation instance. You can call the suspend method of this continuation instance to stop the current request from processing. The suspend method takes a timeout parameter of type long. Once the timeout period elapses or on some notification the request processing can be resumed. An invocation of the resume method resumes the request processing. The continuation object's status verification methods, such as isPending and isResumed, are helpful in checking the current state of the continuation. In nonblocking continuations isPending is set to true for the entire period between the first call to suspend and a subsequent second call to the suspend method. The isResumed method is true once the processing is resumed. If the call needs to maintain state, it's advisable to save it by calling the setObject(Object o) method before a suspend method is called. Once the call resumes, the saved state can be retrieved by calling the getObject method of the continuation instance. Any arbitrary objects can be saved away and retrieved in the context of a continuation in this manner.

The request processing in BlazeDS starts with the MessageBrokerServlet. This is because of the configuration to route all requests to URL(s) with the /messagebroker/* pattern in their name to MessageBrokerServlet. The relevant configuration in web.xml is:

<servlet-name>MessageBrokerServlet</servlet-name>
<servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
....
<servlet-mapping>
    <servlet-name>MessageBrokerServlet</servlet-name>
    <url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>

Now an easy hack to include Comet support and yet not disturb the existing BlazeDS infrastructure very much is to create an HttpServlet that supports continuations and have all calls to a new endpoint, which you may want to call JettyStreamingAMFEndpoint, divert to this new Servlet. The continuations support Servlet could be named ContinuationMessageBrokerServlet.

Within ContinutationMessageBrokerServlet's service method, you want to get hold of a continuation instance and call the JettyStreamingAMFEndpoint's service method by passing in the continuation parameter to it:

Continuation c = ContinuationSupport.getContinuation(req,null);
....
endpoint.service(c, request, response) ;

Within the JettyStreamingAMFEndpoint, you may want to keep stock of all pending requests and put them in a collection called pendingContinuations. Then you may want to include the following to include the functionality of suspending a processing request in a nonblocking manner:

if (!c.isPending()) {
      pendingContinuations.add(c);
    }

    c.suspend(timeout);

When the response arrives, that is, a server side data push event occurs, you want to resume the processing and send the response out. The code is:

c.resume();
    pendingContinuations.clear();

That completes a high-level view of how comet-based data pushing can be included in BlazeDS. Such an option is restrictive to the extent that it will only work with Jetty. In future, as the Comet standards are stabilized and more application servers support it, I expect BlazeDS to start supporting it, too.

I am working on creating an open source robust Comet-supportive data push option for BlazeDS. For now, only Jetty and Tomcat are included in that effort. This open source initiative is christened "dsadapters." The project is hosted on Google Code: http://code.google.com/p/dsadapters/.

That brings us to the end of the chapter on messaging, but before we move to the next topic, let's recap what was covered in this chapter.