What the Bayeux ? No portable (java) code !

Server-side-push (or comet) is gaining interest these days. Therefore, no wonder that the Bayeux specification/protocol is also gaining interest. The primary purpose of Bayeux is to implement responsive user interactions for web clients using Ajax and the server-push technique called Comet. The Bayeux spec is developed by the Dojo Foundation and contains a protocol definition. There is also a Java- and JavaScript-API offered by the Dojo Foundation. The API should be use by consumers when they build server-side soltuions (in YOUR project), extensions or even a Bayeux-based product.

Let’s take a closer look at the Java-API…

The “standardized” API from Dojo is located in their SVN. The (default) implementation of this API is part of the Jetty Container. So far so good… Now, when one decides to use Bayeux in a product, it would be (in theory) as simple as just using the API and getting started! Like you know from standards that are developed by the JCP, e.g. Java-Servlets…

However, there is a problem, today with that… There are several implementations of the Bayeux standard/specification, like:

  • Apache Tomcat
  • Jetty – the default/reference implementation
  • Grizzly
  • Weblogic (HTTP Publish-Subscribe Server)
  • Netty from JBoss (soon)

This is not uncommon in the Java land. For instance, there are several EJB- or Servlet-containers out there. Choice is good! However… the JCP standard, like EJB or Servlet, forces the implementor of the specification to ship (or implement) an unified API, with single and unique namespace like javax.**. In the Servlet-API it looks like javax.servlet.**…

Not so in Bayeux… Almost every Bayeux-implementation comes with a different set of its public API. Huh ? This makes the development of real products – that have to run (and scale) on different application servers – impossible. In order to provide a portable solution you have to know the details of the actual API from the container you want to support.

Tomcat vs Jetty vs …

Let’s take a look at Tomcat and Jetty. Here is the same API, the Bayeux Message, but it is different in detail:

The above Message represents an object that is published to a channel, to be consumed by any other client (the spec explains the terms…).  Basically the above message interfaces try to implement the same contract, but the implementations are all very different and therefore incompatible:

  • different package
  • slightly different in terms the they have different methods defined.
  • etc

So again, if one want’s to provide a Bayeux extension for all containers, he has to know some detail about the API of the “supported” containers. Sounds like you are really tied to a specific container OR you have to do lot’s of extra work…

Of course there is hope, that the vendors agree on a real, unified standard API. Like we know from those APIs that are defined by the JCP. Another interesting option is also the Atmosphere framework. It provides (another) proprietary API to make portable comet/server-side-push solution easy and possible. Under the hoods it hides all the oddness to support multiple different container-specific APIs. Not too bad!

What about the client-side code ?

Yes, Bayeux also has some client-side API. Basically when you use the jQuery plugin or the stuff that comes directly from dojo, you can use any server, since the message-exchange between browser and server is well-defined (in the protocol). So, if you create fancy Web-User-Interfaces you pick usually one library jQuery OR dojo. Or… you create your own client Bayeux API… Your product just ships the picked JavaScript library and you are fine. However replacing jQuery’s Bayeux support with the one from dojo also needs some extra work… but the entire front-end is still portable to other containers… which is not true for the server-side extensions, as said before…

Servlet 3.0

In Servlet 3.0 there will be a standardized API for doing asynchronous request processing. That means frameworks like Atmosphere aren’t needed on any Servlet 3.0 container, since there is:

  • a common, public API (as part of the Servlet-API)
  • the nasty implementation details are simply hidden by the container

Bayeux and Servlet 3.0

With the advent of an Servlet 3.0-based Bayeux implementation, there is hope! Such a solution is actually portable, since the API-implementation will use Servlet 3.0 instead of container-specific APIs. However still one problem is left, the different public APIs from all the available Bayeux implementations (as said before on the Tomcat vs Jetty section)… But with Servlet 3.0 the pain is not that big… You have to decide which Bayeux implementation you want to use and stick it into your product… Since the implementation of the chosen API will run on any container, IF it ONLY has Servlet 3.0 specific code (and NO use of container-specific APIs).

Jetty is coming..

The Jetty container, version 8, there will be a such a portable Bayeux implementation. Good news, and some hope for the near future!



Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: