Sunday, May 25, 2008

More on the "OSGi hype"

I’ve seen more and more people talking about OSGi lately. Some are saying that we are going through “OSGi hype”…

Well, I’ll talk about the OSGi hype here too :)

OSGi is being around for almost ten years. Maybe it gained (more) momentum after Eclipse adopting it since version 3. I’m not sure, I have no "authority" to say that. That's just what I think as an outsider.

A non-exhaustive list of OSGi advantages: no more classpath hell, modules life cycle, dynamic updates with no application reboots, package visibility, decoupling through services.

Several important organizations are seeing OSGi’s value and are investing on it. This guy posted a list of applications using OSGi. We can add Apache Sling , Apache ServiceMix and Project Fuji to that list too, as well as Glassfish. I've worked as part of the team that developed a now extinct product built on top of OSGi. There must be a lot of other not so popular stuff built with OSGi.

Maybe some recent events caused all this hype:

  • JOnAS 5 released as the first (I guess it was the first one) JEE application server to run on top of OSGi.
  • Recently we’ve seen Glassfish using it.
  • JBoss is talking about OSGi.
  • BEA (now Oracle) is using OSGi in its microservice architecture.

I guess OSGi has become the de facto module system for Java. It seems that JSR 277 has a risk of falling into oblivion when it becomes released if it does not converge with OSGi. Since so many important announcements about OSGi adoption are taking place, we are seeing this “OSGi hype”.

In my opinion, this is not hype. It is industry evolution. But those that still do not get it may see it only as hype.

Technology hypes may sometimes lead to some naïve decisions like “let’s use it because it’s a cool trend and everybody is using it. It's a new trend”. Maybe that was a naïve example too...
Before choosing to use stuff like OSGi try to evaluate if it fits your needs. Get to know it better. Maybe taking a look at the docs in the OSGi alliance website or looking for tutorials. Decisions like this involve the architecture of your project.

Whoever tries to use OSGi must be careful with the sometimes steep learning curve. Try to take advantage of existing component models (OSGi declarative services, Service Binder, Spring DM, iPOJO) that handle hard dynamic aspects, service location, dependency injection, and do all the dynamic voodoo magic. There was a time when all that stuff needed to be made by hand. You don’t need to do that anymore.

There is some stuff that is painful in the beginning like “bundlizing” a jar. But constructing an OSGi compliant manifest may be simplified by automated stuff like a bundle plugin for maven. Well, there is plenty of stuff (like here) to minimize efforts concerning OSGi development.

I'm away from the market for almost a year and started (or continued, if you will) to do research that involves OSGi. Each time I see news about its adoption in industry I get even more motivated about my choice.

Even if you don’t buy the idea or if it is useless for you, it is worth taking a look. OSGi is not just a buzzword. Try to use it not because it is hype, check its benefits first.

No comments: