Skip to main content

The Remedy

Posted by editor on May 23, 2008 at 7:30 AM PDT


The increasing prominence of OSGi

Let me admit something: I don't get OSGi. I'm not saying I don't like it, I just don't really understand what it is or why it matters so much. The Wikipedia article isn't much help either, so over the past few months, I've been quietly nodding my head in seeming agreement as OSGi-related posts show up with increasing frequency among our weblogs. Back in April, Mandy Chung blogged about JSR 277 and OSGi interoperability and Supporting OSGi Bundles in the Java Module System (which kind of sound like the same thing, right?), along with Sahoo announcing you can run GlassFish V3 on OSGi, and Jean-François Arcand spoke at JavaOne about Grizzly's OSGi bundles. In fact, there was a lot of talk about OSGi at JavaOne, as noted by No Fluff speaker Vladimir Vivien, among others.

So, granted, it's a big deal. But still, what the heck is it?

Joseph Ottinger, editor of TheServerSide, has posted the first two installments of a series on OSGi. He says the idea is that he, "as a non-OSGi advocate, would like to take some time to try to explain OSGi to the people who don't know about it." And then he tries to get the definition out in under twenty four seconds:

The twenty-four second explanation: OSGi is a framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath, so that it can serve as an independent unit, should that be desireable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container.

Only problem here is that not only is that longer than 24 seconds, it also doesn't explain why you'd want or need a module system. For the complete story, start with his first article,
OSGi for Beginners, which introduces the concepts of OSGI and shows how to build OSGi bundles, register services, build simple dependencies on other bundles, and look up services from other OSGi bundles. A second article introduces The Whiteboard Pattern for OSGi, advocated by some as a more efficient way to use OSGi, with an eye to its strengths and weaknesses.


And, apropos of the OSGi buzz, the latest java.net Poll asks "What's your interest level in OSGi?" Cast your vote on the front page, then visit the results page for current tallies and discussion.


Also in Java Today,
the latest in the SDN's series of Enterprise Tech Tips is Ron Monzillo's Adding Authentication Mechanisms to the GlassFish Servlet Container. "This tip will show you how to implement and configure new authentication mechanisms in the GlassFish v2 servlet container. GlassFish v2 includes implementations of a number of HTTP layer authentication mechanisms such as Basic, Form, and Digest authentication. You can use the techniques described in this tip to add alternative implementations of the included mechanisms or to add implementations of new mechanisms such as HTTP Negotiate/SPNEGO, OpenID, or CAS."

In another JavaOne interview podcast, Barton George is Talkin' with Charlie and Tom, the JRuby Guys. Topics include the history of Ruby, Rails, and JRuby, licensing choices, JRuby's integration with GlassFish and NetBeans, the DaVinci machine project, jMaki, and whether we might see a JPerl.


The latest JavaOne Community Corner Podcast is
j1-2k8-mtT05: Project Wonderland: Community-built Virtual Worlds.
In this session, Nigel Simpson and Nicole Yankelovich show a number of different virtual worlds built by members of the Project Wonderland open source community members. Each highlights different aspects of the Wonderland platform and the wide range of possibilities open to developers.


In today's Weblogs, Giovani

Comments

It's not perfect, but the following blog entry attempts to explain what JSR 277 (and the already existing OSGi) try to solve:

Modularity in the Java Platform

Meaning, that the larger whole isn't predefined. Rather it can be used in different contexts. (For example, NetBeans could do like Eclipse and switch to OSGi. Eclipse didn't always use OSGi, if I understand correctly.)

OSGi: Java classpath management is a pain. OSGi lets you statically or dynamically add, update, and remove libraries in an app without worrying about conflicts so much. It's like the upcoming Java Module (jam) system, but it's available yesterday and covers more use cases.

Modules are to classes what classes are to methods. A way of encapsulating a functional area of code such that it can be independently loaded, tested, re-used, and re-implemented. The slides for the "Converting (Large) Applications to OSGi" JavaOne2008 talk are up on BJ Hargrove's blog: http://blog.bjhargrave.com/2008/05/hot-off-press-my-javaone-presentation... The talk focuses more on the how than the why, but I found some good background info there.

Chris, I have attempted to answer your question "why you'd want or need a module system" on my blog: http://neilbartlett.name/blog/2008/06/06/what-is-osgi-for/

Sounds all like NetBeans Modules to me. Is there something like a comparison Chart or a "OSGi explained to NetBeans Module developers" out there? Will there be anything similar to layer files?

vorgi: Good idea. I don't know NetBeans Modules, but I imagine that they have a lot in common. Also similar to web apps or old-timey applets (before the newfangled process-per-applet model starts to kick in). The point of OSGi (so far as I understand it) is to be focused specifically on this task rather than being part of an expected larger whole.