Over a million developers have joined DZone.

A Dozen OSGi Myths and Misconceptions

DZone 's Guide to

A Dozen OSGi Myths and Misconceptions

· Java Zone ·
Free Resource

Anybody who knows me or has been following me lately knows that I have an interest in OSGi. And I'm not alone--there has a lot of buzz about OSGi in the past few years.

But as I talk about OSGi with other developers, I often hear them say things about OSGi that simply aren't true. It's not their fault, though. Unfortunately, there's a lot of misinformation and misconceptions about OSGi out there. It's hard to sort out the good information from the bad. And more often than not, it's the bad information that sticks with people.

There's no perfect technology and OSGi isn't going to be nominated as the first one. But before you give OSGi the brush off, let me try to set the record straight on a few of the OSGi myths and misconceptions that I've heard.

OSGi is too complex

I've been told that OSGi is too complex because it requires rigorous management of the META-INF/MANIFEST.MF file (you know...that file that's in every JAR file...the on you never look at).

It is true that OSGi leans on the MANIFEST.MF file and that you'll need to make sure that the manifest contains entries that you probably wouldn't normally put in there. But it's also true that OSGi only demands one additional entry in MANIFEST.MF for a JAR file to qualify as an OSGi bundle: Bundle-SymbolicName.

Bundle-SymbolicName is used to identify a bundle (the unit of modularization in OSGi) to an OSGi framework. It typically follows an inverted domain name pattern (similar to how Java packages are named). For example, the Bundle-SymbolicName header for a simple hello world bundle might look like this:

Bundle-SymbolicName: com.habuma.osgi.helloworld.hello-simple

Of course, if all you did was add a Bundle-SymblicName header, you'd have a perfectly valid OSGi bundle that is also perfectly useless. For it to be useful, the bundle needs to...

  • Export one or more packages. Packages within an OSGi bundle are private by default, meaning that they are only visible to classes within that same bundle. For them to be used by other bundles, they must be exported. This involves adding one or more package entries in an Export-Package header in the manifest.
  • Publish one or more services. Services are the way that bundles talk to each other. A bundle can expose its functionality through one or more services. This involves either using a declarative services model such as Spring Dynamic Modules or by creating a bundle activator class that programatically publishes the service through the OSGi API.
  • Do something. Bundles do not have to expose any of their functionality through exported packages or services. They may just sit there and churn on something. For that, the bundle needs to have a bundle activator (or, if you're using Spring-DM, a <bean> with an init-method).

Although there are several headers that you could include in a bundle's MANIFEST.MF, there are only a few that you'll probably ever use. And even then, much of the management of the manifest can be automated using tools such as Peter Kriens' BND (more on this later when I talk about OSGi tools).

Maybe it's not manifest management that makes you think OSGi is complex--perhaps the OSGi API causes you some concern. In that case, consider this: The OSGi API is made up of only a half-dozen different packages and mostly interfaces. Of those, you'll likely only ever need a handful of them.

Even then, you'll probably never even need to use the OSGi API at all. But I'll continue that discussion in the next item...

OSGi is too heavyweight

Whenever I hear the word "heavyweight" in the context of a technology or framework, it usually means that the framework imposes itself and its APIs too heavily upon an application's code. EJB 2.x, for instance, required that EJB implementation classes implement base EJB interfaces and implement a number of lifecycle methods. Consequently, EJBs were considered heavyweight.

On the surface, the OSGi API does appear to be a bit heavyweight. Bundle activators, for instance, are classes that implement the BundleActivator interface, providing start() and stop() methods. For example, here's a simple hello world bundle activator:

package com.habuma.osgi.hello.internal;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public final class HelloActivator implements BundleActivator {
public void start( BundleContext bc ) throws Exception {
System.out.println( "Hello World!" );

public void stop( BundleContext bc ) throws Exception {
System.out.println( "See ya later!" );

The fact that this class imports org.osgi.framework.* interfaces and classes should tip you off that we're not dealing with a POJO. But before you dismiss OSGi as heavyweight, consider this:

  • When developing to the OSGi API, the only classes that really need to implement and use the OSGi directly are the "plumbing" classes that publish and retrieve services and that manipulate the OSGi framework itself. The OSGi API typically doesn't invade the classes that provide your application's business functionality.
  • You often won't need to develop to the OSGi API anyway. It's much easier and more lightweight to use a declarative service model such as OSGi's Declarative Services, iPOJO, or Spring Dynamic Modules. Using these facilities, OSGi services can be published and consumed as POJOs.

Using declarative OSGi, iPOJO, and Spring-DM are topics that are beyond the scope of this article. But I do cover Spring-DM in Modular Java. And watch this blog space for more discussion on it soon.

OSGi isn't a "standard"

Personally, I'm not sure that it should matter much whether something has been stamped as a "standard" or not. After all, Spring isn't a standard. Hibernate isn't a standard, either (although JPA was heavily influenced by it). For that matter, Ruby on Rails isn't a standard. Despite their lack of standardization these frameworks are rarely questioned anymore for their lack of a JSR. Solutions, after all, are more important than standards.

But, if it standards are something that's important to you or your organization, then rest easy knowing that OSGi is, in fact, a recognized Java standard.

Aside from self-standardization applied by the OSGi Alliance, OSGi R4.1 is also the subject of JSR-291 from the Java Community Process. This JSR was given final approval and was released in mid-2007. The ballot included 12 votes in favor (The Apache Software Foundation, SAP AG, BEA, Hewlett-Packard, Nortel, SAS Institute Inc, Borland Software Corporation, IBM, Oracle, Fujitsu Limited, Intel Corp., and Red Hat Middleware LLC), two votes against Those voting against it were (Sun Microsystems Inc. and Hani Suleiman) and two members did not vote (Google and Doug Lea).

In addition, the mobile application of OSGi is the subject of JSR-232 (which is also in final release/maintenance release status).

OSGi is too new

Despite the fact that OSGi has only recently been grabbing the attention of Java developers, OSGi has been around a lot longer than many other readily-accepted technologies. In fact, OSGi celebrated its 10th birthday last month. In its time, OSGi has reached many milestones:

  • March 1999: The OSGi Alliance was founded
  • May 2000: OSGi Release 1
  • October 2001: OSGi Release 2
  • March 2003: OSGi Release 3
  • October 2005: OSGi Release 4
  • May 2007: OSGi Release 4.1
  • Sometime in 2009: OSGi Release 4.2

To put OSGi's age in perspective, consider the "birthdates" of these other technologies and where OSGi falls in:

  • 1995: Java 1.0
  • 1995: Ruby
  • 1996-1997: DVD
  • December 1998: Java 2
  • May 2000 OSGi Release 1
  • February 2002: Microsoft .NET
  • February 2002: Blu-ray Disc
  • March 2004: Spring 1.0
  • July 2004: Ruby on Rails

OSGi has been around nearly as long as several established technologies and has been around much longer than many others.

OSGi isn't ready for the "real world"

The precise definition of "cutting-edge" is up for some debate. Regardless of how you define "cutting edge", there are several projects out there that have been comfortable enough with OSGi to use it. Considering just a few examples...

  • Siemens Medical Solutions and ProSyst Software developed solutions for maintenance of medical devices in the area of image management systems using OSGi. (I love this example because the cliché criteria for how established a technology is if you'd use it to launch rockets or save lives.)
  • Philips developed its iPronto wireless home control panel using OSGi.
  • BMW Research develop innovative "infotainment" and telematic systems in automative projects that are based on OSGi.
  • Since version 3.0, the Eclipse IDE has been based on OSGi.
  • Virtually every major Java application server vendor is engaged in working OSGi into the server products. SpringSource is leading the way with their SpringSource dm Server, the first application server to fully expose OSGi's modular capabilities to application developers.

For more examples of projects that have placed their faith in OSGi, have a look at OSGi Markets and Solutions. And I'm certain that the list isn't complete--let me know if you hear of an interesting use of OSGi that isn't listed.

There aren't many OSGi tools

Perhaps my problem with this myth is that I'm unclear as to how many tools are needed to negate it. Certainly, I will acknowledge that there are some tools that I wish I had when working with OSGi. But I also do not believe that there is a dearth of OSGi tools as some have suggested.

When it comes to OSGi tooling, the very first tool that comes to mind is Peter Kriens' Bnd. Bnd is a remarkable little tool for creating and diagnosing OSGi bundles. Using BND, you can view the manifest and JAR contents of a bundle, wrap a non-bundle JAR file so that it becomes an OSGi-ready bundle, create a bundle given a specification and class path, and verify the validity of a bundle's manifest.

What's particularly interesting about Bnd is that although it comes as a single JAR file, it is actually three different tools in one. If you run it with java -jar bnd.jar, it is a command-line tool. If you add it to the Eclipse plugins directory, it is an Eclipse plugin. And, it has an Ant task built into it, so you can use it in an Ant build.

A fairly recent addition to the OSGi toolbox is SpringSource's Bundlor. Bundlor seems to address many of the same problems as BND, but is supposed to overcome some of BND's limitations. I haven't had a chance to try Bundlor out yet, but from what I read, it looks very powerful. When I get around to trying it out, I'll be sure to blog about it here.

There's also a huge set of OSGi tools available from the OPS4J Pax project. I've already reviewed these tools on this blog, so I won't go into it again here. Suffice it to say that many of the Pax tools have become indispensable in my OSGi development toolbox. I'm particularly fond of Pax Construct, Pax Runner, Pax Exam, and Pax URL. You can count on me blogging more about the Pax tools soon.

Apache Felix is known as one of the leading OSGi frameworks. But Apache Felix also has several subprojects that provide OSGi tools. The vast majority of the Felix subprojects are runtime tools, such as File Install (which automatically installs and uninstalls bundles from a watched directory) and Web Console (which provides a web-based administration console for an OSGi framework). Apache Felix subprojects also include the Maven OSGi Plugin, which is a very handy Maven plugin for automatically generating bundles (with proper manifests) in Maven builds. (BTW, Pax Construct leans heavily on the Apache Felix bundle plugin, which itself leans heavily on BND.)

If you take a visit to DynamicJava.org, you'll find several more useful OSGi tools and libraries. I've not tried any of these out yet, but several of them look very interesting and I hope to give them a spin sometime soon. (If I do, I'll be certain to blog about it here.)

These are only a few examples. If you look around, you'll find a lot of useful OSGi tools...even OSGi tools that work within your favorite IDE. And that brings me to the next item...

OSGi is for Eclipse users

If you've spent any time on Google looking for information on OSGi, you'll find several articles that discuss OSGi in the context of the Eclipse Plug-In development environment (PDE). That, coupled with the fact that one of the major OSGi implementations is produced by the Eclipse Foundation, may lead some to believe that you must use Eclipse to develop OSGi-based applications.

The truth, however, is that there's nothing about OSGi that makes it proprietary to any development environment. Certainly, Eclipse has provided the best IDE for OSGi development for a long time. But if you're an IntelliJ IDEA user, then you should check out Osmorc, a plugin for IDEA that provides support for OSGi development. I am also hearing rumors that NetBeans support for OSGi development is in the works.

That said, I frequently find myself working with OSGi bundles using a text editor like TextMate. That's because most of the OSGi-related work doesn't require anything more advanced than a simple text editor (apologies to TextMate...anyone who has used it will attest that it is far more than just a simple text editor).

OSGi is a solution looking for a problem

I almost didn't include this one. I've been in the software development game for a long time and I know that anytime someone wants to discount a technology or framework, the killer phrase that is almost always thrown about is "XXX is a solution looking for a problem" (or its variant: "XXX is a hammer looking for nails"). But just because someone says it doesn't mean that it's true. But I heard someone say this again recently, so I tossed it in.

I've also been doing this thing long enough to know that modularity is a good thing. Developing software in modules increases maintainability, testability, flexibility, and comprehensibility. It also offers benefits in terms of parallel development and (to some degree) reusability. Many languages such as Modula-2 and MIL-75 have been around for a long time and were created with modularity as a primary concern. Ask around...most everyone will agree that modularity is a desirable trait of good software.

Unfortunately, as awesome as Java is, it doesn't offer a lot of help with regard to modularity. JAR files and packages give only the illusion of modularity. And although there's a certain amount of modularity at the object level, that flavor of modularity is at too low of a level to be truly useful for creating modular applications.

So, if modularity is a good thing and Java doesn't offer support for it, then...well...that sounds a lot like a problem to me. A problem begging for a solution, some might say. And modularity is one of the key things that OSGi offers. So, in my opinion, OSGi is a timely solution to the problem of Java's missing modularity.

I can get modularity without OSGi

It's certainly true, to some extent, that you don't need OSGi to achieve modularity. With the right mindset and a lot of discipline, you can develop Java applications that are modular to some degree.

But the problem is that there's nothing in the Java platform to encourage modularity, much less enforce it. And even the most disciplined and well-intentioned Java developers make mistakes. In short, if modularity isn't enforced, then it probably doesn't exist.

OSGi doesn't strictly enforce modularity (with some misguided cleverness, you can develop poorly defined OSGi modules, too), but OSGi does strongly encourage good modular development. With OSGi, it's easier to develop modularly than not to.

So, yes...it is possible to achieve modularity without OSGi. In the same way, you don't need Spring to do dependency injection. And you don't need an ORM solution like Hibernate or JPA to do object persistence. And you don't need an IDE to develop in Java. And you don't need JUnit to write well-designed, working code. You don't need any of that stuff...but I wouldn't want to give any of them up.

Speaking of testing...

OSGi is difficult to test

Inside of every OSGi bundle is a bunch of Java code that, if well-written, can be tested using JUnit or whatever testing tool you prefer. As with any Java codebase, you are free to write tests at the unit level and also to write cross-unit integration tests.

OSGi doesn't make testing harder--you can still test your code the same way as you do without OSGi. But OSGi offers a new level of testing--integration testing at the bundle level.

Bundle-level testing involves deploying one or more OSGi bundles within an OSGi framework (such as Equinox or Felix) and then making assertions about how those bundles work together, what packages they export, and (even more interesting) the services that they expose.

Testing OSGi bundles "in-container" sounds difficult, but thanks to a handful of testing frameworks, it's actually quite easy. These frameworks are:

The first three of these testing frameworks all work pretty much the same way. After installing a collection of bundles in an OSGi framework (or frameworks) of your choosing, the test wraps itself in an on-the-fly OSGi bundle and installs itself in the framework. From within OSGi, the test is able to use and examine the bundle context, consume OSGi services, and assert that the bundles under test are behaving well.

Of the three testing frameworks listed, I tend to favor Pax Exam because it's currently the only one that is based on JUnit 4. Pax Drone is effectively deprecated in favor of Pax Exam, so unless you encounter a project that's already using it, you should disregard it. As for Spring-DM's testing support, it is nice in that it uses Spring autowiring to autowire OSGi services into a test class. But until it's based on JUnit 4, I still prefer Pax Exam.

DA-Testing is a new entry in the OSGi testing toolbox. I haven't had a chance to try it out yet, but it claims to address OSGi testing in a way that's very different than the first three testing frameworks. When I get a chance to try it out, I'll be certain to blog about it here.

OSGi doesn't have a cool name

Okay...you got me there. I'll concede that OSGi doesn't have a cool name like "Spring" or "Hibernate" or "Groovy". In fact, I'll even agree that "OSGi" is probably one of the most boring names ever given to a Java framework or library.

In my opinion, this is one of the worst things OSGi has going for it. I believe that a lot of the misinformation about OSGi stems from its name. It sounds complex. It sounds heavyweight. It sounds like an unpleasant medical procedure.

My apologies to the OSGi Alliance. You guys are awesome and have done some magnificent work. But the name...well...it needs some work. ;-)

There are no books on OSGi

Not true! There are already a handful of OSGi books available. And with OSGi becoming a hot topic, I'm sure that there will be several more on the way.

One such book that I'd like to recommend is Modular Java. Even though I'm obviously biased toward this book, I can recommend it as a pragmatic example-driven guide to building applications with OSGi and Spring-DM.

Here are some other OSGi books that are available or will be available soon:

Of course, I really hope that you'll start your adventures in OSGi with my book.

I hope that this article has dispelled some of your doubts about OSGi. Of course, I suppose that if you're adamantly opposed to OSGi, then there's nothing I can say that will change your mind. But if you're a reasonable person who has been reluctant to look into OSGi because of what you've heard, then perhaps I've cleared things up enough for you to give it a fair look.

This is the first of several articles that I hope to post on this blog over the next several weeks (or months). I have several great articles in mind, but I have no idea where this will go. I'm going to start by covering a few of the tools that make working with OSGi easy. So keep an eye on this blog for more OSGi goodness coming soon.

From http://www.jroller.com/habuma


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}