OSGi: Modularity without restarts for Enterprise Java applications

People that have kept track of the developments around Java 7 will have noticed that modularity is a term that pops up everywhere; there are several JSRs that concern this topic: JSR-277, now suspended, JSR-291, based on OSGi, JSR-294, a module system for Java that's part of the language itself, and also project Jigsaw, a Sun-initiative for modularising the VM.

Where most of these JSRs discover new territory, OSGi is a standard that has proven itself time and again in various applications already. OSGi came into being as a standard around 1999 in the embedded space. With the limited capacity of this hardware it wasn't an option to start a new Virtual Machine for each application, so multiple applications had to be able to easily and safely share a single runtime. By itself Java doesn't really deliver the necessary support for that: the lineair classpath doesn't allow for working with multiple versions of a library, there is no good option to hide implementation details from other applications and to make dependencies explicit, there is no standard facility to give applications their own lifecycle and finally, there's no mechanism to publish and discover services offered by applications running in the same VM. To allow applications from different suppliers to run together effectively and efficiently in a single VM without having to restart after every installation or upgrade, these are import requirements.

To meet these requirements the OSGi standard was created. This standard is governed by multiple organisations united in the OSGi Consortium. There exist several implementations of the OSGi standard, which is curently at version 4.1: version 4.2 is under active development and will be released later this year. Well-known open source implementations include Apache Felix and Equinox. The latter is especially known as the engine driving the plugin model of Eclipse, the populair Java IDE.

Application of OSGi

For years the application of OSGi was limited to embedded devices (e.g. BMW uses it in their cars) and some special-purpose applications. During the last couple of years, though, more and more interest in OSGi has risen in the Enterprise Java community. Many application servers are already using OSGi internally and there are several frameworks and runtimes available for enterprise application developers to use OSGi themselves. There's also a number of solutions to support developers in dealing with the complexity that a fully dynamic environment like OSGi brings with it: services can come but also go at any moment, so an application has be able to deal with a service becoming unavailable at any point in time. On first sight this seems to only highten the complexity compared to a traditional Enterprise Java application, but when you have a closer look it turns out that handling exactly these types of situations is essential for building robust applications that can continue to run as other applications or services are temporarily unavailable, for instance because an upgraded version is being installed.

A framework that plays an important part here is Spring Dynamic Modules (Spring-DM), an open source framework that integrates the programming model of the Spring framework with OSGi to create a solution where OSGi obtains a full, mature component model. The pioneering work that was done in Spring-DM by employees of SpringSource, former BEA and Oracle is currently being standardized in RFC-124 that will be part of OSGi 4.2. Spring-DM 2 will be the reference implementation of this new standard.

Server-side OSGi

All of this means that a whole new application area for OSGi has emerged: the server side. The possibilities offered by OSGi to nicely modularise applications and to follow a dynamic, service-based approach form a good match for the wishes and requirements that exist nowadays for applicaton servers. For example, it's often simply not an option anymore to completely bring down an application when part of its functionality needs upgrading, let alone following that by a reboot of the server that hosts other applications as well. Also, more and more problems are experienced by having to use multiple versions of third party libraries that applications depend on: often the only solution is to package an application with all of its dependencies (that often make up for far more contents than the application itself) and then to hope that these dependencies are mutually compatible. Also, these dependencies can not already be available in a different version somewhere higher up the classloader hierarchy or you'll have to start tweaking classloader delegation modes and such.

For sharing standard functionality across applications the only real option is to resort to remoting solutions: a facility to offer local, dynamic services that can easily be shared across multiple applications is lacking. An Enterprise OSGi Expert Group is currently working on gathering the requirements that applying OSGi in an enterprise setting encompasses and to standardize some solutions for these issues.

Currently the application of OSGi in most servers is limited to the inside: products like IBM's WebSphere Application Server and Sun's latest Glassfish release make good use of OSGi internally, but that doesn't affect application developers in any way. They simply continue to build their applications in the old Enterprise Java way, where the monolithic applications are deployed as big stovepipes to the servers without much interaction or modularity. The market is shifting, though: various products are becoming available that target the use of OSGi on the server side, like Infiniflow from Paremus. These products enable their users to develop enterprise applications that profit from the features that OSGi has to offer. They do, however, require a different way of working than what most enterprise developers are used to. One of the reasons that most application servers don't exposes OSGi to the application developers yet is that its usage, besides the benefits explained, also introduces some problems of its own. Most of these problems are caused by the fact that many existing enterprise libraries and frameworks contain code that's not compatible with the OSGi model, which enforces very strict visibility rules. For example, by default a library canot 'see' code from the applications that use it, while the workings of many modern libraries are based on exactly this principle. This means that e.g. libraries cannot dynamically generate code based on application code: in OSGi this is not possible without further configuration, as these libraries do not explicitly declare a dependency on the depending application code.

The SpringSource dm Server

A different solution in this area is the SpringSource dm Server. This is an application server that's based on Apache Tomcat, Equinox and Spring-DM. The purpose of dm Server is to enable developers to make use of OSGi in their own web and other enterprise applications, while still being able to use existing libraries and frameworks like Spring and Hibernate. The big difference with the other application servers is that OSGi isn't just used 'under the hood': application developers kan start to use OSGi modules (so-called 'bundles') themselves to modularize big applications that communicate with each other through a service oriented architecture.

This is not a SOA in the usual sense: the individual modules are still running on the same server, but their dependencies have been made explicit and services provide a much looser coupling. This has several advantages. One of them is a greater potential for reuse: multiple applications can use the same code, or even the same services. With multiple applications runnning on a single server this often means less memory usage as well: libraries need to be loaded only once per server instead of per application. The server itself is set up in a modular fashion as well, so that unused functionality can easily be disabled. This means faster startup times and less resource usage. For example, the embedded Tomcat server can be disabled completely if there are no applications employing a web interface.

To benefit from these advantages, it's necessary that all used libraries are available as OSGi bundles with the proper meta-data. For many populair open source libraries, this is currently not the case. To meet the demand for bundle versions of third party libraries, SpringSource has started a separate project: the Enterprise Bundle Repository, available under http://www.springsource.com/repository. Via this application, hundreds of enterprise java libraries can be downloaded as proper OSGi bundles. These versions are made available for free and can be used with any OSGi implementation, so not just with the dm Server.

An important feature that the dm Server adds to plain OSGi is the concept of an application, consisting of multiple bundles: a so-called Platform Archive or PAR-file. By packaging bundles as an application you obtain a unit of mainenance, so that things like deployment and monitoring of an application become much easier than is the case with individual bundles. This concept also offers a form of 'scoping', where types and services within an application are not visible to other applications. One of the benefits offerered by this encapsulation is that multiple versions of a single application can now run on the same server without causing conflicts. Code that is intended to be shared across applications is of course still available, but is simply not packaged as part of the application.

Furthermore, the dm Server provides solutions for working with enterprise libraries that use techniques that don't work within a standard OSGi environment, like dynamic code generation or 'weaving' of code, as used by many JPA implementations. It also offers a full solution to work with web applications, something that OSGi itself only has limited support for.

Conclusion

It's clear that OSGi is a rising star within the Enterprise Java world. The benefits of being able to work in a truly modular fashion attract many developers. Many application servers are using OSGi already, and with innovative products like Paremus Infiniflow and the SpringSource dm Server the use of OSGi becomes available to application developers as well.

It will take a while before OSGi has become mainstream technology for server side development, but it seems undeniable that Enterprise OSGi is a development that we'll see a lot more of over the coming years.