OSGi - Feast or Famine?
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?
From http://techdistrict.kirkk.com/2010/04/12/osgi-feast-or-famine/





Comments
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.
James
Alosh Bennett replied on Tue, 2010/04/13 - 6:07am
Jacek Furmankiewicz replied on Tue, 2010/04/13 - 9:13am
The problem for OSGi is that it is often oversold...as 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
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...
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.