Web applications are the most common type of deployments on the application servers.
So, if OSGi is going to be a serious contender in the application server market, I would expect it to have great support for deploying web applications using WAR files. So, I looked through the existing documentation on eclipse.org and played with Equinox, Tomcat and Jetty. Here is what I have learned so far:
There are two ways to integrate Equinox’s implementation of OSGi into your server-side environment:
- Embed your web application server within OSGi server
- Native OSGi HTTP service implementation of Servlet API 2.4
- Jetty-based implementation - Also requires the usage of the dynamic OSGi HTTP Service.
- Embed OSGi server into your existing web application server
- Equinox Bridge Servlet (Front controller servlet)
- Dynamic OSGi HTTP Service using the Equinox Bridge Servlet
Option #1 means that the developer is forced to use OSGi HTTP Service. This is great for new web applications built from scratch. The user can programmatically register the servlets and add service listeners to listen for any events (if any one of these instances are started, stopped or updated, we are notified). But, this complicates the development effort required for making an existing WAR file work with this setup. Traditionally, Servlets have been considered “static” – They do not have to be installed/started/stopped dynamically. So, the “dynamic” OSGi HTTP service becomes an overkill in this particular case, IMO. The other disadvantage of this approach is that not all aspects of the Servlet spec are implemented here. For ex., Servlet Filters are not yet available in the native OSGi HTTP service implementation. I am not sure how clustering can be achieved here.
Option #2 uses the standard “Front-controller” pattern and uses the Bridge Servlet as a Front controller servlet. org.eclipse.equinox.servletbridge and the Servlet API are exported automatically to the underlying OSGi framework. So, the modules deployed in the OSGi server have access to the Servlet API to register/unregister servlets. This approach obviously uses the web.xml. So, you can add more servlet mappings for JSPs, if necessary. The other sub-options here revolves around using this Servlet bridge to provide the dynamic OSGi HTTP service.
So, I do not feel comfortable with both of the above options provided by Equinox OSGi implementations. Perhaps, other implementations might have better solutions.
No wonder the folks at SpringSource chose not to implement OSGi HTTP service in their SpringDM server platform for now. They support the standard WAR file deployment within their embedded Tomcat server. This seems like a pragmatic approach to me to support all the existing standard Web Application Archive (WAR) files.
Although I like the other dynamic services (Logging, Configuration, Event Admin Service, etc.) in the OSGi Service Compendium, I am not so sure about the HTTP Service, especially for existing web applications.
What do you think?
