Websphere 7 & OSGi

Blogger: Kirk Knoernschild

I recently spoke to Tim Francis, IBM Distinguished Engineer, and Walt Noffsinger, product manager for Websphere Application Server (WAS), about WAS 7, which was released in October. WAS 7 has a few significant new features, and Walt pointed out that enterprise customers are especially excited about three of them - flexible management options, business level applications, and runtime provisioning based on OSGi.

While the first two are rightfully cool, it's the latter where I want to focus. Few are aware that WAS 6.1 was redesigned and packaged as OSGi bundles. But the capabilities of the OSGi Service Platform were not exposed to the enterprise developer. And in fact, WAS 6.1 didn't take advantage of the dynamic capabilities of OSGi. Instead it was just laying the foundation for what was to come in WAS 7.

WAS 7 improves upon the 6.1 implementation in a key way. Whereas WAS 6.1 was packaged as OSGi bundles, WAS 7 leverages this capability through dynamic provisioning of only the capabilities that are needed. So if an EJB container isn't needed, the EJB Container bundle isn't started. This reduces startup time for applications and also reduces their memory footprint. While those are real advantages, that's where the advantages of OSGi stop in WAS 7.

Tim mentioned that the WAS team has always taken backward compatibility very seriously, and that's evident with WAS 7 still supporting J2EE 1.2. And to ensure that compatibility, more complete bundle lifecycle capabilities will have to wait on the OSGi Enterprise Expert Group, of which IBM is a participant. That includes exposing the benefits of OSGi to the enterprise developer, who are still left dealing with the Java EE deployment model along with any proprietary goodies offered by the container. The dream of a dynamically adaptable application platform, and developers realizing the advantages of OSGi, are starting to arrive. Hopefully, there will be more to come.

Comments

[Paul Benedict]

I am waiting until OSGI bundle information in jar manifests are honored inside a war. Will WAS 7 provide that?

[Kirk Knoernschild]

Not in WAS 7. WAS 7 confines the benefits of OSGi to WAS. Development teams cannot deploy OSGi bundles to WAS 7. The only way to take advantage of OSGi in WAS 7 is to embed OSGi within your application.

[Joost Winne]

Have you got any links to how exactly embed OSGi in a WAS (6.1) application?

As an example requirement (jar hell):
I want to use two jars inside a web application: 'a.jar' and 'b.jar', where 'a.jar' requires 'log4j.1.1.jar', and where 'b.jar' requires 'log4j.1.2.jar'.

Both 'a.jar' and 'b.jar' do not expose log4j.

How can I make this happen (using two versions of log4j in one web application)?
Can I simple put 'a.jar', 'b.jar', 'log4j.1.1.jar' and 'log4j.1.2.jar' in the WEB-INF/lib folder in the WAR file of the EAR file (and put those special OSGi manifest files entries in those jars) and let OSGi save the day in some way?

How can I make sure the WAS uses the OSGi classloader mechanism instead of loading all in the application classloader (which results in arbitrarely loading classes from the two log4j jars, mostly coming from version 1.1 because its jar name comes lexicograficly first)?

I don't want to use that commandline tool to install, start/stop libraries. I don't need the dynamic features. The only OSGi feature I really need is: "a seperate classloader for each jar".

All tutorials about OSGi start with explaining the console install/start/stop, but nobody explains OSGi in a J2EE environment, the main existence reason for Java?