Industry Use of OSGi Continues to Increase

Posted by Scott Delap on Aug 10, 2006 02:56 PM

Community

Java

Topics

Business

Tags

Podcasts,

OSGi,

Equinox,

Eclipse

OSGi is a specification of a Java based service platform targeted for use by systems that require long running times, dynamic updates, and minimal disruptions to the running environment.. The Eclipse Equinox project provides one of many available implementations of this specification (EclipseZone recently featured a podcast with Equinox project lead Jeff MacAffer) and serves as the reference implementation of the latest OSGi R4 specification. Initially, OSGi was targeted at home automation and residential gateway devices. More recently, it has found use in everything from mobile phones to cars.

The OSGi specification breaks software up into units of functionality called bundles. As a result this makes OSGi an idea base for applications such as IDE and application servers that often have numerous "modules" that may or may not need to be started at runtime or after the application has been started. The Eclipse IDE has made use of OSGi as its base since version 3.0. More recently other applications have started leveraging OSGi.

One recent use of the Eclipse Equinox technology is to bundle servlets and JSP's in Eclipse style plugins for dynamic WAR deployment. The Apache Tuscany SOA project has recently started exploring OSGi.  Websphere 6.1 and JOnAS 5 are also being reworked as OSGi applications. A case study published by Adobe details how they made use of OSGi in their Adobe Creative Suite 2 application:

... [team members] found that reusing Adobe Creative Suite 2 components in an Equinox environment was as simple as writing a thin compatibility layer.

Developing plug-ins to deliver new functionality in the past had presented significant challenges. Since it was difficult to validate dependencies, Version Cue had not been able to make the most efficient use of system resources by loading exactly what was needed. Using Equinox and the Eclipse plug-in model, resolving plug-in dependency is simple, and they have been able to achieve true dynamic loading and unloading of plug-ins on demand. The result is a smarter, leaner and faster application that provides a better user experience.

Developers in the trenches are also starting to notice OSGi. Xerto's Imagery application is built on Swing but uses OSGi for its plugins layer. Blogger Werner Schuster recently commented:

if you want to write any kind of nontrivial program where you want a clean seperation of the individual modules. If you do that, you can spend ages writing a runtime system that tediously reimplements all the OSGi features,.. or you can just use OSGi. And it will pay off… OSGi isn‘t a new kid on the block… it‘s now up to version 4, not to mention that Eclipse has used it now for about 3 years and provided lots of feedback. I became really convinced of OSGi usefulness when I had some class loading issues while writing EclipseShell… I already feared having to mess with the classloaders (not much fun if you‘re using JVM based dynamic languages which might or might not pack their own class loading tricks). But no! The solution to my problems was … adding a line to the Manifest.MF ... et voila! (If you‘re curious, google for “Buddy-Classloading”)...

So… screw Sun‘s NotInventedHere syndrome, screw Dolphin, screw waiting for JSR-277 to be shoved into existence. The future is here right now and it‘s tried, tested and easy to use in the form of OSGi, Eclipse for development, and Equinox for the runtime.

It will be interesting to see how the Java community makes use of OSGi which is available today versus Sun's "super-packages" (JSR 294) and Java Modules (JSR 277) initiatives scheduled for Java 7. A blog post by Sun's Alexis Moussine-Pouchkine described the two JSR's:

JSR 294 is development-time and language driven while JSR 277 is all about deploy-time ... one of JSR 294's goal is to enable "separate compilation", i.e. compile against an interface without needing the actual implementation. Most of JSR 277 has to do with annotating JSR 294 modules. Pretty much like moving archive manifest information to Java annotations.

1. Back to top

   An interview is in order...

   Aug 10, 2006 4:01 PM by Rafael de F. Ferreira

   How about an interview with expert group members for those JSRs? I feel they are a bit too silent, and that is really worrysome for specs with potential to have such a big impact on the future of java development.

   Reply

2. Back to top

   Re: An interview is in order...

   Aug 10, 2006 5:47 PM by Floyd Marinescu

   Great idea, we're on it. What questions would you have for them that you'd like us to ask?

   Reply

3. Back to top

   Re: An interview is in order...

   Aug 11, 2006 4:44 AM by Neil Bartlett

   I have a question for the JSR 277 guys. Like all JSRs, 277 must answer the standard formation questions, one of which is "Why isn't this need met by existing specifications?". If a JSR cannot answer that question satisfactorily then it should not exist. The answer given for JSR 277 discusses a few alternatives in order to reject them; specifically JNLP, WARs, EARs, "Class-Path:" etc, and finally OSGi Release 3. However OSGi R3 is the old version, we are now on OSGi Release 4, and it is R4 that is being brought into the JCP as JSR 291. There are no arguments offered as to why OSGi R4 does not meet the need, and in fact all of the reasons given for rejecting OSGi R3 (and they are valid reasons) no longer apply to OSGi R4. Therefore, given that an existing specification does already meet the need that JSR 277 intends to meet, why is JSR 277 still needed?

   Reply

4. Back to top

   Apache use of OSGi

   Aug 11, 2006 9:01 AM by J Aaron Farr

   Apache is currently incubating an OSGi implementation called Felix. Some of the Java-based Apache projects have looked into adopting OSGi for their own internal container.

   Reply

5. Back to top

   Re: An interview is in order...

   Aug 11, 2006 7:16 PM by Rafael de F. Ferreira

   Some things I would like to know:

   • A simple overview of the programming (and deployment) model with JSR-277 and JSR-294. Something similar to the published slides from the JSR-277 JavaOne BoF.
   • Every developer hates committing to a deadline, but I must ask anyway: when should we expect to see a public early draft?
   • JSR-294 was formed several months after JSR-277, was it a spin-off or a separate development?
   • Anyway, those two JSRs appear to be nicely collaborating. It is no secret that Sun was opposed to JSR-291 (OSGi "rubber-stamping"), but it was accepted nonetheless. How is the 291 expert group interacting with 277 and 294?
   • Is there any provision for dynamic extension management? (something similar to Eclipse extension repository). If not explicitly, is it possible to
   • easily
   • create something of the sort on top of JSR-277
   • Do any of those JSRs provide Service Locator or Dependency Injection (IoC) mechanisms for component discovery?
   • Do any of those JSRs define a component lifecycle model?
   • Is there any plan to retrofit the plethora of existing component (or quasi-component) models in Java in order to adapt to the new model? I'm thinking of EJB, WAR, JBI, JMX, etc.

   (Sorry for my English)

   Reply

6. Back to top

   Re: An interview is in order...

   Aug 12, 2006 1:58 AM by Rafael de F. Ferreira

   I forgot that I had one more question: * Is fixing bug 4670071 within JSR-277's scope?

   Reply

7. Back to top

   Re: An interview is in order...

   Jan 4, 2007 2:46 PM by Glyn Normington

   I forgot that I had one more question: * Is fixing bug 4670071 within JSR-277's scope?

   Sun have developed an experimental fix which will be refined in Dolphin with feedback from the JSR 277 Expert Group.

   Reply

• Older >