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