For me, an interest in Eclipse internals resulted in my first encounter with OSGi. By now, OSGi has gained serious momentum in the entire Java ecosystem and I feel that OSGi is a topic that every Java developer should be aware of. In this article, I intend to guide you past the online resources that I found most relevant for gaining knowledge of OSGi. Hopefully, readers will agree with my selections and gain an understanding of OSGi and why they are likely to encounter it in the near future, if they have not already.
The OSGi home page states that “OSGi technology is the dynamic module system for Java”.
The modularity, which includes explicit declaration of dependencies, allows greater control over coupling between components (such as in uncovering unwanted coupling and version management). A life cycle definition handles the dynamic loading and unloading of modules; after being loaded modules then cooperate using the Service Registry. A security model is present to keep modules from misbehaving.
With these OSGi facilities, applications are assembled in a way that can be described as “SOA inside the VM“.
A comprehensive presentation about OSGi by evangelist Peter Kriens is available online.
Origins of OSGi
The inclusion of companies like Nokia, Nortel and Ericsson in OSGi’s members list hints at the origins of OSGi: initially created as a platform to be used in home automation (R1 and R2), it has been used in vehicle automation (R3), mobile devices and the Eclipse Project (R4).
The Java enterprise community has also started to take notice, with interest growing especially in the past two years. OSGi history and the new enterprise interest are discussed in an interview with Peter Kriens.
In response to the newly emerging usage, OSGi has formed the OSGi Enterprise Expert Group (EEG). Enterprise requirements such as distributed environments, additional security and messaging are investigated in this group and will be part of the next release of OSGi.
The history of OSGi is addressed again, as well as the formation of the EEG, in an interview with EEG co-chair Eric Newcomer.
The JCP approach to modularity in Java: JSR277 and JSR294
Within the Java Community Process, JSRs JSR277 and JSR294 have been created to have modularity as a standard part of the Java language.
The discussion about OSGi vs. JSR277+JSR294, has by itself helped generate interest in OSGi because even if people were not yet interested in modular development, everybody loves an online slugfest.
Work on JSR 277 has been ongoing, but the debate seems to continue.
As a sidenote, OSGi 4.1 has been approved as a Java specification through JSR291.
OSGi for developers
One of the most eye-catching areas where OSGi has greatly risen is that of application servers. Many major application server vendors transformed their products into OSGi applications. This allows them to create several differently packaged server offerings, which contain only the modules that customers want.
Since OSGi is dynamic, it opens up the possibility of changing the server while it is running, e.g. for security updates or capability upgrades. The level of integration with OSGi varies, as sometimes OSGi is just used internally, while in other application environments the OSGi context is explicitly shared between the server and the client applications such as Java EE components. Whatever your deployment target is, you are likely to encounter OSGi to some extent.
Sun states that the well-known application servers are now considered legacy, to be replaced with GlassFish.
Modularity is defined as one of the primary goals for GlassFish 3.
In line with Sun’s support for JSR277, a proprietary module system (HK2) was developed, including a runtime environment.
Since GlassFish V3 Technology Preview 2, this has changed somewhat and the Felix OSGi runtime will be the default runtime environment for GlassFish 3. Internally, the application modules do not use OSGi; its HK2 system is still used as an abstraction on top of OSGi for backward compatibility and to support the additional features that were implemented through it, such as a module repository.
According to a article comment apparently by GlassFish developer Sahoo Sanjeeb, interaction between EE and OSGi components has not yet been realized.
SpringSource Application Platform
SpringSource’s Rod Johnson claims that Spring+Tomcat is currently the most popular application server.
After the release of Spring Dynamic Modules, it was not immediately clear if SpringSource wanted just to help developers leverage the increasingly popular OSGi, or use it as a means to propel SpringSource’s own strategy.
The answer has come with the SpringSource Application Platform.
For his platform, SpringSource created a module repository (Enterprise Bundle Repository), through which SpringSource helps developers use tools and libraries that do not have standard integration with OSGi, such as Hibernate.
WebSphere Application Server
IBM’s Version 6.1 of WebSphere Application Server is delivered as a set of OSGi bundles.
For now, this seems to have more impact on the deployment side (with changes in some classpath handling) than on the development of applications for WSAS.
Application developers cannot access the OSGi functions inside their own applications when they are deployed on WSAS.
BEA created their microService Architecture based on OSGi.
In WebLogic Event Server, the OSGi core is exposed to programmers through Spring and used to create adapters.
Version 5 of the JonAS application platform has also been converted to OSGi internally.
In JOnAS, the OSGi model is exposed to the deployed applications. Using annotations, the OSGi context can be injected into EE components.
JBoss has also done a major overhaul with version 5, but the new microcontainer is not OSGi-based.
Instead, JBoss 5 will contain JBoss’s own OSGi implementation inside the microcontainer .
Eclipse Runtime project
Another contender in the “enterprise Java without JavaEE” corner is the Eclipse Runtime Platform project, Equinox (confusingly enough, Eclipse’s OSGi runtime itself is also named Equinox).
As one of the early projects where OSGi became visible in the mainstream Java development community, Eclipse has a strong presence in the OSGi world.
Eclipse’s take on enterprise applications seems different than that of other vendors. In Eclipse RT/Equinox, applications are built using tools that differ even more from the JEE paradigm than Spring.
For example, RCP and its web-enabled sibling RAP more resemble ‘ye old fat client programming model’ than the generally web application oriented approach used by the other vendors.
Writing your own OSGi-enabled applications
So OSGi is out there. Should you jump on the bandwagon and start using it in your applications?
A rather academic view on OSGi adoption in existing applications has authors Donagata, Kozakov and Hahn state that “most of the legacy code requires at least minor changes and can’t be ‘bundle-ized’ as it is.” This is also recognized by OSGi’s Peter Kriens.
In a more technical two-part article, Aslam Khan writes: “OSGi has gained prominence because it is being used to address some tough problems in Java enterprise application development and software architecture in general. There are several problems that can be tackled using OSGi”.
As can be learned from the other’s experiences with converting their applications to OSGi (such as shared by BEA and Sun’s Andi Egloff ), benefits can be great, even if only from the discipline enforced by modularity.
When you develop applications with the SpringSource Application Platform or the Eclipse Runtime project, OSGi will be there for you to ignore or take advantage of.
If modularity is a requirement for your application, OSGi should certainly be considered, since it can be used now (as opposed to JSR277) and has a proven track record in many applications.
Specific Java EE features that your application needs may restrict you to a Java EE deployment platform.
Some application containers allow combination of OSGi and Java EE, but the binding will probably be container-specific, reducing portability.
As mentioned earlier, the OSGi Enterprise Expert Group works hard on adding to OSGi what is needed for a complete enterprise experience.
Distributed OSGi solutions exist, and input from the enterprise Java companies such as SpringSource will be included in OSGi R5.
Tools like Terracotta and Gigaspaces may provide alternatives for requirements that were traditionally covered by J2EE.
An important difference between JSR277 and JSG291/OSGi 4.1 is the added notion of a module repository in JSR277.
As more and more applications and libraries are made available as OSGi bundles, it seems logical to create a repository for modules. This is where OSGi kind of meets Maven.
From OSGi itself, there is an RFC for a Bundle Repository, of which a preliminary implementation is already available.
Other repositories exist as well:
The SpringSource Enterprise Bundle Repository provides a lot of commonly used open source libraries as bundles to be used in OSGi applications, relieving application developers from the task of converting those themselves.
GlassFish has a GlassFish-specific module system, with its own update center.
For Eclipse’s own projects, Orbit serves as a central bundle repository for references outside the Eclipse Project.
Some tools are available to help developers work with OSGi. Being OSGi-based Eclipse has the Eclipse Plugin Development Environment for bundle development. Another important tool is bnd, which helps create bundles with ant and maven. In the deployment phase, File Install allows management of deployed modules through the file system.
Getting your hands dirty
This article does not include its own tutorial or examples, but these can be found in many places, such as at BEA, JavaWorld, and in Neil Bartlett’s book (a work in progress, but the introduction seems complete enough).
It is probably also a good idea to take a look at the OSGi best practices, which include topics such as concurrency and potential issues with listeners.
OSGi maintains a list of introductory references on their Basic Education page.
OSGi is a mature specification that can provide value in the development and maintenance of applications.
It has been adopted by all Java industry leaders and may be on the way to become a pervasive technology in all Java development.
You may decide not to use a modular framework or a different one (e.g. NetBeans or the original HK2 from GlassFish); perhaps wait for JSR277.
Otherwise, the resources referenced in this article should enable anyone wanting to learn about OSGi to get started.
I enjoyed getting to know OSGi, and I hope you appreciate my efforts in noting what I found interesting.