Web Forefront

OSGi's most notable presence so far has been as the Eclipse Runtime -- the open-source Java IDE project that goes by the same name, as well as other projects which require to operate under constrained environments such as J2ME. But what exactly is OSGi ? Some have classified it as a classloader framework, while more adventurous definitions include : what Java EE should be. But since a picture is worth a thousand words, here you go, just so you can create your own first impression :

Source Wikipedia.org Osgi layer

The key concept behind OSGi is that of a "bundle", a module/application that can be managed with a great level of detail, when compared to the classical methods available in Java [Along the lines of JMX and Java EE containers, more on this follows].

In Eclipse, OSGi success has stemmed from managing these 'bundles' which for practical purposes are Eclipse's plug-ins. A plug-in, in this particular case is of course a Java module/application which requires to be 'bundled' in such a form, to address the more sophisticated requirements -- install, start, stop, update and uninstall -- present in an IDE environment and which aren't supported directly by a JVM.

But now, OSGi is making in-roads with this same approach on server-side Java, something which I believe stands to make serious changes in this space, so let me explain and provide you with more resources on the subject to uphold this statement.

Though I'll be the first to admit, the mere mention of framework on server-side Java makes my eyes turn "do we really need yet another Java framework ? ", the traction OSGi has gained recently is worthy of attention.

If you look back on server-side Java developments, you will notice that the way components were built/'bundled' in the first incarnations of application servers (a.k.a containers), have long since fallen out of flavor in favor of more so called 'lightweight' frameworks/containers. These lightweight frameworks/containers which tout the POJO("Plain Old Java Object") mantra and include Spring and Pico among others, showed remarkable adoption rates in server side Java projects from the start, much to the dismay of the existing 'heavyweight' techniques.

Tough the primary heavyweight on the server side -- Java EE -- took queues from many of the successful approaches employed by its lightweight competitors, such as revamping EJB 3 with these 'old' tricks, these changes along with future proposals in Java EE have created an apparent rift in server side Java, leaving a clear opportunity for OSGi to step in.

My first encounter with OSGi stepping into Java server side territory was with BEA's microService Architecture (mSA) , right up there you will read: "At the heart of the backplane components is the OSGi framework which provides the capabilities to intelligently load, unload, and hot-swap modular software components that are delivered as OSGi bundles."

At first I thought it was more marketing spin, but then I encountered this more eye opening read from Greg Brail who works at BEA: Using OSGi at BEA . In it you will find the following : "We're using OSGi as the framework to build future BEA products. That means, for instance, that a few new products in the pipeline won't run on top of WebLogic Server, but neither will they start from scratch with a pile of JAR files."

That's interesting, especially the "new products in the pipeline won't run on top of WebLogic Server", so what will happen with WebLogic Server, BEA's Java EE flagship ?? He goes onto say: "As for Weblogic Server, you'll have to wait and see. There are people working on modularizing that product and integrating parts with OSGi at the moment. What the WLS team chooses to do will depend on what our customers ask for."

Touche with what 'customers ask for', but is this BEA / OSGi / Java integration initiative an isolated case ? Well, a little more research will reveal that the Spring framework -- which already has major presence in server side Java -- has a Spring-OSGi project , not to mention, Apache has also been working on an OSGi implementation named Felix which recently came to top level Apache status.

And it doesn't stop there, further inspection into the language-agnostic SOA community, already shows signs that OSGi is also getting into the playing field, in this space you can find a series of post by IONA's Chief Technology Officer Eric Newcomer : OSGi for the Enterprise , OSGi for the Enterprise - update and Importance of OSGi for the Enterprise , as well as a white paper published by OSOA entitled Power Combination: SCA, OSGi and Spring [PDF Format].

And of no less importance -- though published on the OSGi blog -- you can find Can Someone Tell Sun About OSGi? which goes into Java EE 6 (yes! SIX, as in the next version) not acknowledging what OSGi has to offer, and Why OSGi Technology is Strategic .

So what does all this mean? Does this mean obsolescence for Java EE ? More confusion and overlap around SOA terms JBI, SCA, ESB ? At this point it would be just speculation, but what you can surely count on is that OSGi will become an even more familiar name in the years to come in enterprise server side projects.

Update : I wrote an extensive technical article on the use of OSGi for server-side Java, in it you will find a hands on sample on using OSGi with Apache's implementation named Felix, as well as the impact OSGi will have on the future of some Java developments. You can read the introduction OSGi on the server side and follow to link at the end to get the full length article at BEA's dev2dev site.