The Grizzly framework is used in multiples products like GlassFish, Sailfin, RESTlet, OpenESB and many more, where it enables developers to write scalable server applications, by leveraging the Java New I/O API (NIO). Atmosphere, an evolution of Grizzly, is a POJO based framework that aims to bring Comet to the masses. Jean-Francois talks to InfoQ about this new development.
InfoQ: Jean-Francois could you describe to us the benefits of using a framework like Grizzly and what are the common ways you see people deploying it?
Jean-Francois Arcand (JFA): Writing scalable client or server side applications is not an easy task. The benefit of using Grizzly framework is that you can create such powerful applications without having to deal with low level NIO concept. Grizzly allow you to write such application in a very simplistic way, helping speeding up the time required to develop client/server side applications. The Grizzly community is also really active, answering questions and fixing issues really fast, making the development experience really smooth. An active community is always a plus for any open source project, and over years we have grown and learned a lot from our community.
InfoQ: In the newly released version 1.8, the Grizzly framework packs various modules that can co-exist or be installed independently. Could you give us a short description of these modules and a brief architectural overview of the current release?
JFA: Grizzly modules can be separated into two categories: The NIO Framework and its extension. The NIO framework can be used to build powerful server side application. As an example, I've worked with Ericsson (via the Sailfin project) to implement the SIP protocol support on top on the Grizzly framework module. The SIP protocol support TLS, UDP and TCP as transport, so they only viable solution was to use the framework. Another example is the Sun's Shared Shell product, which also build on top of Grizzly Framework. The second category is what I call the embeddable component like the http, jruby and comet extension. Those can be used directly or can be embedded. A good example is GlassFish v3, which build on top of the http module. We also have an experimental half baked Servlet Container (not finished) that can be used for testing purpose (ex: with junit). Project Jersey is using it for their automated testing, and so far it proved to be quite useful as a very tiny Servlet-like container.
InfoQ: Grizzly is used in many other open source projects, both inside of Sun Microsystems and outside, the most prominent being the GlassFish Application Server. Could you give use some other examples that best demonstrate the power of the framework?
JFA: With open source, it is always a challenge to find who is using your stuff. The one I know are: (Outside Sun) 4homemedia.com, RESTlet, Jetty, Alt-mobile, Mediafed/blog-city, T-mobile, Yahoo Brazil, Bindows Ajax Framework etc. (Inside Sun) GlassFish, JXTA, Phobos, JavaCaps open-esb http binding, Jersey, GlassFish v3 Grail implementation, Netbeans, Sailfin, Sun Shared Shell, Sun Instant Messenger, The GlassFish JRuby gems build on top of our Grizzly's JRuby on Rail extension. Grizzly Comet is supported by ICEFaces and DWR for the client side. We have probably many more, they just don't tell us :-)
InfoQ: How do you see Grizzly with respect to competition from Tomcat or Jetty?
JFA: The main difference between Grizzly and Tomcat/Jetty is really that they fully support the Servlet 2.5 specification, where Grizzly isn't (yet :-)). Where Grizzly competes is for the embedded space. I think there is really a need to have a small http runtime that can be easily customized. I think this is where Grizzly can be a good alternative to Jetty/Grizzly (smaller, easier to extends, etc.) Jetty is leading that space, but we are seeing more and more application switching from Jetty to Grizzly. One advantage Grizzly's have is its asynchronous request processing mechanism, that can be customized at the http level. That mechanism seems to be quite popular for writing tiny asynchronous proxy. Grizzly http extension allows you to write Comet based application without the need for Servlet support, which is sometimes required.
InfoQ: What about the the Servlet 3.0 Specification (JSR 315) that aims to provide inherent support for Comet?
JFA: Right, The Servlet 3.0 is working to add official API support for Comet. Mainly, a way to suspend/resume request is being discussed.
InfoQ: Would you like to describe to us what the Atmosphere framework is all about and what where the driving forces that led to it?
JFA: Two years ago I've blogged about the Grizzly Comet Framework, and since that time I was able to build a community around it. One of the drawback of the Grizzly Comet Framework is it only work with Grizzly runtime and GlassFish, which is a severe limitation. Over the year, peoples have asked to port the framework to other container like Tomcat, Jetty and Resin. So my goal with Atmosphere is to take the best from the Grizzly Comet Framework (one component who is called Grizzlet) and made it working with all container, supporting Comet or not. This way peoples don't have to wait for the Servlet 3.0 spec before being able to write portable Comet/Ajax Push application. It also brings much more than what the Servlet 3.0 Spec will offer.
InfoQ: What about support for the Bayeux publish/subscribe protocol in both Grizzly and Atmosphere?
JFA: The Bayeux implementation can probably be implemented on top of Atmosphere. But for now, I will focus on Atmosphere itself and make sure I can grow a community around it. Once release 1.0 will be done, we will see if we can makes the Bayeux protocol working on top of it.
InfoQ: What will be the future of Grizzly with respect to Atmosphere? Is the new framework a replacement?
JFA: Atmosphere will just move the comet activities from Grizzly into a new project. Recently we have moved our grizzly-jruby extension into a new project called GlassFish scripting. Atmosphere will be our second extension to graduate to a new project.
Grizzly main component, NIO framework and its http extension will stay under the Grizzly umbrella. We are actively working on Grizzly 2.0 right now (with a new lead so I can concentrate on Atmosphere) and a lot of activities will also happens on that side.
InfoQ: What is the timeline, both for the release of Atmosphere and the next version of Grizzly?
JFA: Grizzly 2.0 is targeted for December 2008. As for Atmosphere, it will really depend on how the web community reacts and helps. Since there is no standard right now in terms of Comet API, a lot of container specific code will be required and the help of the community will probably speed up the release and stability. So far I would say that version 0.1 (my original proposal and first release) should happens during the next summer.
InfoQ: Will there be any new tools released, that support the new framework? Maybe a NetBeans plugin?
JFA: For sure having IDE support is on the radar. Build it support for Maven is also something I want to have.
InfoQ: How do you see projects Grizzly and Atmosphere growing in the immediate future to accommodate scalable applications and the Comet programming paradigm?
JFA: One of the benefits of Atmosphere is that it will allow me to compare the Grizzly Comet implementation performance with other container. I guess Grizzly will benefit from Atmosphere because any performance problems discovered by comparing with other framework will help improving Grizzly performance.
Grizzly community will probably continue to grow independently of Atmosphere as the embedding market is growing those days, and grizzly is one of the few that can be easily embedded. One demo I've recently saw was grizzly comet running on the iPhone, which I found amazing . I'm pretty sure more and more examples like that will appear over the next couple of years!
InfoQ: Jean-Francois, thank you very much for your time.
For more information about Comet and Reverse Ajax you can visit: http://www.infoq.com/news/2008/01/comet-scalability
