If you are following my blog, you probably know that I am recently investigating the modularity of the GlassFish v3 and see how it is using the OSGi technology. The main reason for this is that I see some similarities with DaliCMS, the open source "Web 2.0 ready Content Management" system we developed with LodgON and that runs on top of GlassFish.
With DaliCMS, customers have a very functional Content Management System that also includes some "Web 2.0" features, and that especially allows the quick integration of third party "Web 2.0" stuff.
The total functionality is huge, and although we have some customers that in my opinion really are using almost everything that is possible with DaliCMS, the majority of the customers is only interested in a part of the functionality.
More specifically, customers outside the CMS world often benefit from some Dali components. We currently serve them by either building something small based on the specific components they need, or by installing the full DaliCMS product on top of a full GlassFish v2 stack.
Clearly, this approach has some drawbacks. It is much nicer and more elegant if the project-specific software only contains code that is really used. On the other hand, you don't want to rewrite the specific functionality over and over again.
Some customers just need a tool for managing incoming RSS feeds, or they require only a forum where people can vote for each other, or… .
The same is happening with GlassFish. The GlassFish v2 product really contains a lot of functionality. And there probably are some big projects that use 90% of the code in GlassFish. But many projects only require a webcontainer, and no EJB-container or transaction system. People working on those kinds of projects might opt for other solutions, since "GlassFish is too big".
The OSGi approach provides a possible solution for this. We need a modular system, where inter-module dependencies are solved by meta-information (the manifest file) and by the framework.
A customer project is than created by combining the required modules. The OSGi framework provides more than just a mechanism to combine modules. The separation between interfaces and implementations allows for vendor-interoperability. The lifecycle management allows for dynamic updates of different modules, taking into account the specific requirements on other modules. And there is much more.
We are currently investigating how DaliCMS can be split up into a number of OSGi bundles. These OSGi bundles will have dependencies on some other bundles, some of them might come from GlassFish v3. In the end, we will be able to provide each project with a specific system, based on modules that are used in other projects as well.
DaliCMS is an Open-Source effort, hosted as a GlassFish incubator project. Feel free to join the project, or drop me a note at johan (at) lodgon.com.
Johan's blog 