Actually it’s the other way around. The new Glassfish application server model is all about OSGi modules. There is an Apache Felix base container (OSGi container), and in there we have a whole collection of modules deployed on Felix. The servlet container module, the JBI ESB module, and so on. It is possible to maintain Glassfish in the traditional way through the admin console. But it’s also possible to reach the Felix engine through the command line. Both ways are usefull, when maintaining a production environment.
Modules
As simple as possibly said, an OSGi module is an ordinary JAR file with some extra META data. When deployed on the OSGi container, it knows what kind of module it is, what dependencies there are, what version it is, and so on. There are several hands-on books explaining these basics. One book called “Modular Java” published by Pragmatic Bookshelf, is a good starting point to get well oriented inside the OSGi framework.
Hot redeployment
People who worked on Glassfish v2 or v2.1, know the problem when trying to update Glassfish. It doesn’t always go that smooth, and we always have to restart Glassfish for taking the changes into account. With Glassfish v3 this all will be history. Thanks to the new module architecture, it is possible to update modules without shutting down Glassfish. It is just Felix running on the background, and keeping hold on the list of all modules and versions. There is even a web application you have to deploy for yourself, that gives a list of all Modules installed on Felix including bundle number and so on. Only to move from Glassfish v2.1 to v3 will be a migration process, rather then an update.
Felix does support OSGi fragments
Most books on OSGi published this moment talk about Apache Felix not supporting OSGi Fragments. To publish web applications as modules, this is one of the things it needs. OSGi fragment support is also needed if you like to use the new Spring Dynamic Modules (Spring DM) framework. Most of the books promote Equinox as OSGi container, because Equinox does support fragments. It is true that Apache Felix version 1.4 does not support fragments, but fortunately Felix version 1.8 contains all the necessary fragment functionalities. And because Glassfish v3 is released on Felix 1.8, it is possible to incorporate fragments and Spring DM.
People still have the choice to use another OSGi container like Equinox or Knopflerfish.
Applications
Thanks to OSGi it is now possible to have a 24/7 runnable application server. There’s a dynamic classload management, that keeps hold on modules. On the simplest level it is possible to hot redeploy common libraries on the lowest level, keeping all dependencies wired. We have the full power IoC and DI concepts by Spring, combined with the dynamic classload abilities supported by the OSGi API.
For deploying and communicating with a Service on classlevel, it is not needed anymore to write seperate lookup code that references interfaces through JNDI. OSGi has an own build in lookup support. A service is deployed as module, and that module is registered in the list of active modules. As module registration name mostly the service interface name is used. With Spring DM it’s even not needed anymore to write explicit OSGi code to get all the common functionalities. These are all configuration issues, and can be implemented in a declarative way inside the Spring configuration.
Expectations
We expect Glassfish v3 released around december 2009. Also people from Glassfish ESB, WebSpace / Liferay, project Fuji, and so on, are preparing their deliverables as OSGi modules. Anyway there is a big impact going on to ensure upfront Java technology for the next coming years.
Leave a Reply