OSGi and Spring DM: Enterprise Beans, JEE Containers and WEB UI

[Ivano Pagano]

Hello,
me and my colleagues have been interested by the OSGi framework since a couple of years and intrigued as we learned that Spring was integrating his framework with it.

What I care the most is the issue of porting all our web applications and the services offered by the container (like EJB, Task scheduling, Persistence and such) to a possible new application server based on OSGi technology.
Is it possible to softly migrate using some of the existing features within the Spring DM container, and updating the applications gradually?

I mean, what is the level of integration and compatibility with other existing "mainstream solutions".

The same question applies to web UI frameworks, having understood that web application development is not fully supported by the Spring DM container yet?


Thank you for your time
Ivano

[Craig Walls]

First, let me clarify: Spring-DM is a framework that's part Spring and part OSGi that runs on top of an OSGi runtime (such as Equinox or Felix). Spring-DM is not a container itself. Spring dm Server, an application server that is based on Spring-DM and Equinox does provide Tomcat as a web container, but that's a different thing altogether.

Spring-DM does support building OSGi-enabled web applications. But, it's a completely different model than your traditional web container (such as Websphere, let's say). In a traditional web server, you deploy you app (as one big WAR file) in the web container and wish it well. In the OSGi model, your web app is deployed in the OSGi framework alongside other bundles...among them a web container implementation.

In Spring-DM you have the choice of letting Tomcat or Jetty do the web serving job. But in either case, Tomcat/Jetty is just a handful of bundles that are deployed in the OSGi framework along with your application's bundles.

The gotcha here is that in this model, you can't build an OSGi application and then expect to deploy it in a traditional application server such as Tomcat or WebSphere. You must deploy it in the OSGi model. I can fully understand how that may make some people uncomfortable, as it is a new frontier, so to speak.

Three things make it all worthwhile anyway:
- Most/all application server venders are moving toward OSGi, so the different models may converge in the near future.
- SpringSource dm Server already offers a "next-generation" model that is fully OSGi-enabled, but still resembles the traditional model in many ways.
- Using things such as the OSGi-Servlet Bridge let you have some OSGi goodness in a traditional web container. (I have some more detailed opinions on the OSGi-Servlet Bridge, but I'll save those for another post or unless someone asks.)

As for EJB or other JEE support in OSGi...I know of no EJB implementation in OSGi, but it's theoretically possible. I see no reason why EJB infrastructure couldn't be developed as a set of bundles to be deployed in OSGi...I just don't know if anyone has done it or even cares to try.

[Ivano Pagano]

Thank you for your quick reply, Mr. Walls.

When I spoke about a container, I must have been confused and thought of Spring-DM Server, but your post made things much clearer.
If you'd like to share your impressions on OSGi-Servlet Bridge I'd be grateful since that's another interesting point of investigation for me.
Good day to you all

Ivano.

[Craig Walls]

Ivano Pagano wrote:If you'd like to share your impressions on OSGi-Servlet Bridge I'd be grateful since that's another interesting point of investigation for me.

First, I think that long-term there will be no need for the bridge. I think that because I think that long-term all application servers will expose the OSGi development model in much the same way that SpringSource dm Server already does and therefore, there's no need for a special bridge.

But until then...if you want to achieve some of the benefits of OSGi, but must deploy to a traditional web server, then the OSGi-Servlet Bridge is a must.

The bridge works like this: You create a web application that has a special servlet (the bridge servlet) in its web.xml. When the web application is started up, it also starts up an OSGi runtime and installs a collection of bundles that make up that application. As the bridge servlet handles requests, it dispatches them to OSGi services that implement the javax.servlet.http.HttpServlet interface. So...the bulk of your web application still lives in the OSGi runtime, as services. The traditional part of the web app just has the bridge servlet to delegate to those servlet services.

To my knowledge, there are two implementations of the servlet bridge:
- The Equinox implementation: http://www.eclipse.org/equinox/server/http_in_container.php
- The DynamicJava.org implementation: http://dynamicjava.org/projects/dynamic-servlet-bridge

By far, my favorite among these two is the DynamicJava.org implementation. I like it mostly because I like the way they are thinking about having some OSGi bootstrap loader load the bundles for you. But, what I don't like about it is that they use their own DA-Launcher as that bootstrap loader and I would much prefer to use Pax Runner. So... (and this is where it gets a bit technical)

I've dug into the DynamicJava.org bridge and discovered that it is actually quite decoupled from DA-Launcher. It just uses a special servlet context listener to start DA-Launcher and then drop the OSGi bundle context in the servlet context for the bridge to use. Well...what if I were to implement a different context listener that did the same thing, but uses Pax Runner instead? Then I could use their bridge with Pax Runner...win-win!

But...alas...I haven't had time to implement that context listener. But if I did, then I could develop a rather thin WAR file that uses the bridge to delegate to servlet services in an OSGi runtime that is loaded up when the web app starts up. Here's the good part: The bundles that are loaded into the OSGi runtime do not even have to be embedded in the WAR itself! They can reside almost anywhere that Pax Runner can find them (including, but not limited to, the filesystem, at HTTP URLs, in a Maven repo, in an OBR repo, in a ZIP file, etc, etc). I can deploy the thin bridge part of my app in WebSphere (or whatever container I want) and keep my application elsewhere. (Think about it awhile and you'll realize how awesome this idea is. )