Home | Ciber
Knowledge page of Ciber Netherlands

Encountering OSGi

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.

I am certainly not the first to look into OSGi:
Wikipedia has an entry on OSGi, and OSGi articles have been written long before this one by Glyn Normington, Alex Blewitt and Neil Bartlett.

OSGi?

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

Application environments

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.

GlassFish 3

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 Weblogic

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.

JonAS

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

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.

Module repositories

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.

Tools

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.

Conclusion

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.

Marijn Bekers

9 Comments so far

  1. Alex Blewitt June 30th, 2008 19:57

    Dank je wel!

  2. david June 30th, 2008 20:18

    Great overview!! It almost seems to be a response to this: http://dlinsin.blogspot.com/2008/05/osgwhat.html

  3. Mike Francis July 1st, 2008 9:32

    Hugo, an excellent summary of the increasing interest and activity around OSGi. If you are interested in OSGi in teh app server/runtime and further distributed, resilient, scalable runtimes then you may want to take a look at Infiniflow (www.paremus.com) and its open source foundations, the Newton project (http://newton.codecauldron.org).

    In addition you might also be interested in our latest newsletter which had an opinion piece on the increasing interest in OSGi (http://www.paremus.com/news/newsletter/e-news-200806-index.html).

    Regards
    Mike (Paremus)

  4. admin July 1st, 2008 13:05

    Hi Mike,

    I just posted the artikel but haven’t written it. It was written by Marijn Bekers.

    Regards,
    Hugo Hendriks

  5. Sahoo July 1st, 2008 13:59

    It is not true that GlassFish v3 modules do not use OSGi. They all are OSGi bundles in addition to being HK2 modules. We use HK2 for some advanced services.

    Thanks,
    Sahoo

  6. Marijn Bekers July 1st, 2008 22:40

    Sahoo, sorry if I misinterpreted your description of the new GlassFish architecture.
    In the article that I linked, you wrote “By limiting ourselves to HK2 APIs, we are not able to take advantage of rich module management APIs that OSGi provides”.
    Doesn’t this mean that internally, only HK2 is used?

  7. Sahoo July 3rd, 2008 4:05

    The modules are all both HK2 modules as well as OSGi bundles. When the implementation requires to use the services of the module system, they go through HK2 APIs. We have a small layer that implements HK2 APIs on top of OSGi. This layer is used when the server runs in OSGi environment. When the server runs in HK2 only mode, this layer is not used. Hope this is clear now. For further questions, please use users@glassfish.dev.java.net mailing list.

    Thanks,
    Sahoo

  8. Confluence: ?????? ? ???? July 29th, 2008 10:56

    OSGI ?? ???…

    ????? ????? OSGI Alliance…

  9. links for 2010-11-09 « ?? ???;;; November 10th, 2010 1:29

    […] Encountering OSGi | CIBER Knowledge (tags: article blog components eclipse history technology software programming osgi java j2ee tutorial architecture introduction terracotta) […]

Leave a reply