Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
Industry Use of OSGi Continues to Increase
Posted by Scott Delap on Aug 10, 2006 02:56 PM
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.
RelatedVendorContent
Download the Free Adobe® Flex® Builder 3 Trial
Adobe® Rich Internet Application Project Portal
Give-away eBook – Confessions of an IT Manager
Related Sponsor
The Adobe Flash Platform provides everything you need to develop applications, content and video across operating systems and devices.
An interview is in order...
by
Rafael de F. Ferreira
Posted
Aug 10, 2006 4:01 PM
Re: An interview is in order...
by
Floyd Marinescu
Posted
Aug 10, 2006 5:47 PM
Re: An interview is in order...
by
Neil Bartlett
Posted
Aug 11, 2006 4:44 AM
Re: An interview is in order...
by
Rafael de F. Ferreira
Posted
Aug 11, 2006 7:16 PM
Re: An interview is in order...
by
Rafael de F. Ferreira
Posted
Aug 12, 2006 1:58 AM
Re: An interview is in order...
by
Glyn Normington
Posted
Jan 4, 2007 2:46 PM
Apache use of OSGi
by
J Aaron Farr
Posted
Aug 11, 2006 9:01 AM
-
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.
-
Great idea, we're on it. What questions would you have for them that you'd like us to ask?
-
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?
-
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.
-
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.
-
I forgot that I had one more question: * Is fixing bug 4670071 within JSR-277's scope?
7 comments
Watch Thread Reply