Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

OSGi - Feast or Famine?

  • submit to reddit

I want to be careful here, but also very clear - I advocate OSGi and modularity, though am concerned about its future. In some circles, OSGi is hailed as a disruptive technology; in others, it lives in relative obscurity. There are some indications that adoption is growing, and possibly at some point, it’ll catch like wildfire. But right now, OSGi is the most widely acclaimed technology that nobody is using.

Maybe I’m too harsh. Or too impatient. Maybe I need to give it more time. I know some will argue that people are using OSGi, and they’re right. Some are. But of the more than 6 million Java developers worldwide, those using OSGi and designing modular applications is only a very small fraction.

So what’s the problem? What’s needed to drive adoption? How will OSGi and modularity succeed?

What’s In a Name?

One of the greatest inhibitors to adoption has been platform support. Until recently, few platforms exposed the virtues of OSGi to the enterprise developer. That’s beginning to change, and should help drive adoption. Another obstacle is tooling, which I discussed a while back when lamenting that one of the biggest barriers to adoption is no migration path. With better tools, we’re beginning to overcome that challenge.

But will it be enough? Will platform support and great tools help drive adoption? Sadly, possibly not. And part of the problem, I believe, has very little to do with the technology, and much more to do with its image.

So, what’s in a name?

OSGi is the dynamic module system for Java!

Modularity - Old and Stodgy

Recently, I commented on a recent conversation I had with a conference organizer and his reluctance to accept my speaking proposal on modularity. The general sentiment was that it’s an old, boring concept that can be traced back 40 years! He was interested in my talk on agility, but I explained that given the choice, I’d prefer to speak on modularity.

Currently, I’m participating in a similar conversation with the organizers of the Agile 2010 conference on a few sessions I’ve proposed on modularity. And now, Peter writes about a similar experience. This sends an important message to the OSGi community, and highlights an important challenge surrounding modularity. The message: Modularity is boring! The problem: The importance of modularity, and its support as a first class citizen on the Java platform, is not well communicated nor understood.

Not a Technology Problem

This is a serious problem that requires attention. In his post, Peter suggested that micro-services may be a more apt term for OSGi services, so as not to confuse the term with web services. He even hints at proposing a new JSR that would introduce the idea of micro-services as a new primitive on the Java platform. This is a good start, and micro-services isn’t a bad idea, but more needs to be done. The problem is not that OSGi isn’t a great technology with real benefits, the problem is that nobody cares about modularity.

Possibly it isn’t that they don’t care, but instead that modularity won’t sell. Nobody wants to buy a 40 year old technology, they want to buy the next great thing. And without question, developing modular software is not a new idea. But in general, the ideas surrounding SOA were not new either. Yet, without question, SOA has garnered significantly more attention than OSGi over the past decade. SOA has had its day in the sun; OSGi and modularity have not.

This is not a technology problem. The real problem is that OSGi doesn’t have a clearly articulated identity that explains why an organization must be using it, and organizations will adopt OSGi only if its adoption can be tied to real business benefits. Just like object-orientation in the 1990’s and SOA in the 2000’s, each were sold with a wonderful accompaniment of benefits that would reduce cost, speed delivery, model the real world, blah, blah, and blah. Whether they did or did not help organizations realize these benefits is arguable. Whether each were widely adopted is not!

Crossing the Chasm

OSGi has the potential to be this decade’s most disruptive technology. Unfortunately, the virtues of OSGi run the very real risk of never coming to fruition if it’s unable to cross the chasm. And sadly, it can never cross the chasm unless we find an effective way to sell, or reinvent, modularity.

Foremost, OSGi, modularity, and micro-services do not represent the paradigm shift that’s necessary. Too often, we talk about OSGi in terms of its technical merits alone. Unfortunately, that’s not enough. If OSGi is to cross the chasm, it is going to require something different. Something that people can really latch onto. Something that gets them excited. Modularity isn’t enough. Nor is plug-in architecture. Nor any other technically superior thing that OSGi is.

Naturally, this is only my perspective. My opinion. But OSGi has been a widely acclaimed technology for several years, and it has achieved very little enterprise adoption. While the move by SpringSource to donate dm Server to the Eclipse Foundation was hailed as a great contribution to open source, it’s also a clear indication that adoption of dm Server was gaining little traction.

Now, it is possible that an 800 pound gorilla could throw their weight behind OSGi and modularity that will help drive enterprise adoption. Maybe IBM’s move to expose the virtues of OSGi to the enterprise will be enough. With other vendors following suit, and up and coming vendors such as Paremus on the rise, that just might be enough. But if it is enough, I still believe the enterprise isn’t going to buy OSGi and modularity for the reasons we believe they should, they’ll buy something else very trendy in which OSGi and modularity plays a central role. Something new. Something fashionable. Because as I recall Ivar Jacobson alluding to at a keynote a couple of years ago,

The software industry is more driven by fashion than the fashion industry.

Sad. But true! And hopefully when it happens it won’t dilute the value of OSGi and modularity.

Ignore my Rant if You Want

OSGi is a great technology solution. But we also recognize that technologically superior solutions often fail to win. One of the most popular stories is of the video tape format wars. So my little pontification here should in no way be interpreted as questioning whether OSGi is capable, but instead whether OSGi will.

You can choose to ignore me if you’d like, scoff at me, or call this a rant. Maybe I’m just impatient. Either way, I’ll still continue to proclaim the virtues of OSGi and modularity. I believe in it…firmly! But the nagging feeling I have surrounding its ability to cement its place in the world of enterprise software development will continue to tug at me. And I wonder…will it ever succeed? And if so, how? And…when?

What do you think?



Published at DZone with permission of its author, Kirk Knoernschild.


Stephen Houston replied on Tue, 2010/04/13 - 1:42am

Part of the problem with OSGi is the difficulty in just getting a simple web application to work. Most developers don't have time to fight with the OSGi run-times when they know it would simply work on a servlet engine. Getting common tools like Hibernate to work shouldn't be such a chore.

 (Yes I know its easier with Spring DM server, but that ties you to a particular run-time)

James Sugrue replied on Tue, 2010/04/13 - 3:19am

You raise some fair points here Kirk. The exception to all this of course, is those who are developing using the Eclipse platform, in particular RCP applications. Almost without knowing, you can take advantage of all the benefits of OSGi modularity, without any setup complexity.


Alosh Bennett replied on Tue, 2010/04/13 - 6:07am

To add to James's comment, GlassFish V3 uses Felix as the OSGi runtime and would be pushing OSGi to lot man people without they knowing it.

Jacek Furmankiewicz replied on Tue, 2010/04/13 - 9:13am

The problem for OSGi is that it is often if solved every programming program (with no mention of the massive increase in app complexity, building and testing that it brings).

In many cases the reality is that there is no need for modularity just for the sake of modularity: we have 4-5 separate Maven web apps, deployed as WARs and those are our "modules".

So there are alternatives to modularity that are simply easier to implement. My year-long experience with OSGi has been nothing but a nightmare and I vow to never go back to this technology. Too much hassle for too little gain.

It's great for Eclipse or app servers, but for regular business apps it's overkill.

Just my $0.02

 P.S. At least when my Maven web app breaks I know exactly where. In OSGi if I get some obscure ClassCastException within an app consisting of 300 modules, good luck trying to figure out what's wrong.
it's basically looking for a needle in a haystack at this point.


Doug Barnum replied on Tue, 2010/04/13 - 10:00am

Well Kirk because of YOU (the terrific articles you have written that I have read the last 10 months or so) I started dabbling in OSGi for some "home" projects (one released one not yet). I must say it is difficult for me NOT to use OSGi now. I don't use eclipse or any special UI tool (vim, ant and bnd) so my use of OSGi is quite on "purpose". I just love the higher level of modularity and it's not fun to give that up. I do have to say to get OSGi used in my regular job has not happened yet. I have attempted to sing the benefits to my bosses and so far there hasn't been a business opportunity to justify it's use as of yet. Unfortunately I more often have to do what I'm told rather than do what I want (and is the RIGHT thing to do). I did have one chance to use OSGi in a new project however the funding didn't come through. If it re-emerges it will be OSGi for sure as I have already convinced the Project Manager on using OSGi.

Jonathan Doklovic replied on Wed, 2010/04/14 - 9:04am

You should also checkout the Atlassian Plugins Framework it's basically an open source "framework" that can be embedded into any app to enable OSGi plugins.

I've used it for many apps and it makes OSGi actually fun and removes some of the pain...

  • Automatically installs, configures and manages apache felix 
  • Provides developers with maven tools for easier development
  • Provides a simple plugin.xml to define services, imports, exports, etc without having to know OSGi headers
  • Uses bnd at runtime to turn the plugin.xml into a proper OSGi manifest
  • Integrates spring dm
  • Provides a simple API for creating new types of plugins/plugin descriptors/extension points

Chas Emerick replied on Sun, 2010/04/18 - 8:51am

+1 to Jacek above.

OSGi appears to have very little to recommend its use at the application level.  It clearly provides tremendous advantages to framework and platform authors, who would otherwise be rolling their own module systems -- and, if your app needs a plugin system, that portion of it would benefit from OSGi (or really, any other useful, reliable module system).  Until there's a pain point that would motivate authors of "vertically-integrated" applications to give up the simplicity of not bothering with the hassle of a module system, OSGi is likely to continue being ignored by developers building applications.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.