OSGi: Out of the Gates

When Eclipse 3.0 shipped in June 2004, it included many evident improvements. Less visible below the surface was a complete redesign of the plug-in architecture, which controls the vast majority of Eclipse's functionality. Eclipse itself is mostly a framework—actually more like a backplane—into which various plug-ins are loaded and executed. So, the editing, debugging, unit testing capabilities and numerous other activities are all provided by discrete plug-ins. By swapping different plug-ins in and out, developers can customize Eclipse in hundreds of ways.

Until Eclipse 3.0, the plug-in architecture was proprietary; that is, open and documented, but specific to Eclipse. This specificity created two problems: It saddled tool vendors with a one-off project to provide their product to Eclipse users, and it tended to discourage development by open source contributors. In addition, the Eclipse 2.x architecture didn't allow dynamic loading of plug-ins. If you wanted to load and use a plug-in, you had to restart Eclipse. So, when designing version 3.0, IBM decided to change the framework and opt for a standardized, dynamic architecture. Ultimately, it settled on the Open Services Gateway Initiative (OSGi), a Java modular technology historically used in embedded devices (see Michael Yuan's "From Headless to Rich UI" in the May 2004 issue).

OSGi was conceived in 1999 by a consortium of vendors (see www.osgi.org) as a way to design a portable, open interface for platforms that employ plug-ins to add or extend functionality. Originally designed for broadband devices in the home (such as set-top boxes and cable modems), automotive applications and handheld platforms, it has enjoyed fairly wide adoption in these three areas. (The BMW series 5 and 6 use OSGi, as do several models of Nokia handsets.)

While originally intended for small systems, nothing in OSGi's design prevented it from being deployed on the desktop or even on a server. This scalability wasn't lost on IBM, a key player in the OSGi consortium. The company previously had sold an implementation of OSGi in its Service Management Framework, which is a part of the IBM WebSphere Everyplace embedded software platform, so it had an appreciation of what OSGi could deliver. Based on its knowledge of the platform and comparisons with several alternative possibilities (the primary one a new ad hoc design), Big Blue chose OSGi for the Eclipse 3.0.

OSGi Overview
The OSGi framework defines the connection architecture and the services offered to individual plug-ins, which are called bundles in OSGi parlance. The framework itself consists of several layers, all of which run on a single Java virtual machine:

• The modules layer defines a strict model for dynamically loading bundles, and also handles a few consequences of the plug-in model. For example, in Java, a single classpath specifies where all classes and resources are located. The OSGi modules layer provides private classes that a module might need (which are located on a private classpath), and controls any linking needed between modules.
  
• The lifecycle layer is principally concerned with bundle monitoring and management.
  
• The service registry handles key aspects of the interactions among various services provided by bundles. Its principal activity is to control object sharing between bundles; it also defines several events that respond to the coming and going of services, some of which can be fairly involved, such as serving HTTP or providing Bluetooth connectivity.
  

A dynamic plug-in environment has certain constraints not normally found in standard applications, principal among which is the nature of bundle interaction. For example, a bundle must not assume that another bundle's functionality (or data) is present without first checking. The other side of this constraint is that a bundle must not close down without checking the dependence of other modules on it. For example, a document-display bundle can't close down while the spell checker is running. Management of these interactions is handled by these various layers, principally the modules layer and the service registry.

Security is provided by the Java 2 Security model, which has yet to be compromised by buffer overflows or viruses. (Actually, given the amount of Java software running today, this security record is one of the platform's most underappreciated features.) OSGi extends the Java security model in ways that make sense for a plug-in architecture: private classes, for example, and the dynamic management of access permission to specific resources.

In addition to layers and security, OSGi specifies numerous services that can optionally be provided by the framework implementation. Many of these services involve housekeeping, such as the start level service, which specifies which bundles must be started together and how this start is sequenced in relation to other bundles.

At the applications layer, OSGi provides several useful services. The first is a preferences service, which holds user/application preferences, similar to the Windows registry or the Java preferences class (java.util.prefs) introduced in Java 1.4. The HTTP service I mentioned earlier can do quite a bit: In addition to handling requests and posts, it also runs servlets provided by bundles. This capability provides OSGi applications with an embedded Web server—one that can be updated remotely with new servlets that are loaded without requiring the application to restart. Pretty cool, huh? The OSGi framework complements this functionality with XML parser service. Embedded applications will benefit from Jini and universal plug-and-play (UPnP) services that are also part of OSGi. As you can see, the OSGi framework is a well-thought-out and fully functional platform for designing highly modular software.

A framework into which discrete components can be placed, and where they can avail themselves of numerous services—if this seems reminiscent of J2EE, it should. In many ways, the OSGi framework can be viewed as a client-side container, or more properly a non-server container—a sort of J2EE without the complexity and the seemingly endless passel of disparate technologies.

Programming OSGi
Programming for OSGi isn't terribly difficult. To begin with, you need an existing framework into which you can plug the bundles you'll be developing, and there are several free frameworks available. The first, of course, is in Eclipse itself. See the directory entitled org.eclipse .osgi_3.0.1 (in version 3.01 of Eclipse) for the basic JAR files. The directory org .eclipse.core.runtime_3.0.1 contains another JAR file that's needed for the basic framework.

Like the Eclipse framework, an OSGi implementation called Oscar is open source, free and regularly updated. The entire download (including two JAR files and the documentation) is smaller than 1.5MB, which gives you some idea of how lightweight the OSGi framework is.

Knopflerfish is the other major open source OSGi framework. At one time it was a closed-source product under the aegis of Gatespace, a company that was one of the leading members of the original OSGi Alliance. Like the Oscar site, Knopflerfish provides an extensive collection of open source plug-ins that demonstrate how bundles are developed.

Developers must be concerned about two aspects: the actual Java code and a manifest (given the familiar Java name manifest.mf), that contains metadata about the bundle. The manifest identifies the bundle to the framework, indicates its dependencies on other bundles, specifies what function starts up the bundle, and lists any services the bundle provides or consumes. The manifest is a simple text file, such as this typical OSGi manifest:

 
Manifest-Version: 1.0
Created-By: 1.4.2_04-b05 (Sun Microsystems Inc.)
Bundle-Activator: org.pz.osgi.swtDemo
Bundle-Name: SWTDemos
Bundle-Description: how to run SWT from a bundle
Import-Package: org.osgi.framework, 
             org.eclipse.swt.widgets, 
             org.eclipse.swt.layout, 
             org.eclipse.swt
Bundle-Category: example
Bundle-Config: !/config.xml
Bundle-Classpath: .
Export-Service:  
Import-Service:  
Bundle-Vendor: Frank Thomas
Bundle-Version: 1.2.0
Build-Date: June 6, 2004
 

Manifests with more involved dependencies can be fairly lengthy. As a result, Eclipse 3.0 generates these manifests automatically, when bundles are written using its plug-in wizard.

The Bundle-Activator entry identifies where the framework should go to start up the bundle. This Activator class has two methods, which must be implemented: start() and stop(). Here's a sample implementation, the code for a simple Activator class:

   public class Activator implements BundleActivator {
          public static BundleContext bc = null;
          private HelloWorldThread thread = null;

          public void start(BundleContext bc) throws Exception {
                  System.out.println("SimpleBundle starting...");
                  Activator.bc = bc;
                  this.thread = new HelloWorldThread();
                  this.thread.start();
          }

          public void stop(BundleContext bc) throws Exception {
                  System.out.println("SimpleBundle stopping...");
                  this.thread.stopThread();
                  this.thread.join();
                  Activator.bc = null;
              }
 }

The start() method calls HelloWorldThread(), which is the main function of this bundle; it prints the words "Hello World!" to the screen every few moments. Here's the code, a working function that's called from the Actuator:

    public class HelloWorldThread extends Thread {
         private boolean running = true;

         public HelloWorldThread() {
          }

          public void run() {
                  while (running) {
                           System.out.println("Hello World!");
                           try {
                                  Thread.sleep(5000);
                           } 
                           catch (InterruptedException e) {
                                   System.out.println(
                                              "HelloWorldThread 
                                                 ERROR: " + e);
                           }
                  }
          }
 
          public void stopThread() {
                  this.running = false;
          }
 }

The previous code listing is mainly intuitive: It prints out the canonical introductory programming greeting, pauses briefly, and repeats the cycle until stopped. This example neither consumes nor exposes a service to other bundles. If it were to, the code would be somewhat more complicated—but only somewhat. The OSGi team did a terrific job of keeping the framework out of the way. (Recall that it was originally designed for embedded contexts, so code bloat was hardly welcome.) Both code listings (the simple Activator class and the working function) need only be made into a JAR file and accompanied by the appropriate manifest file to be ready for use. [Editor's note: The previous code listings are taken from a tutorial by Sven Haiges; see "OSGi Resources" for more information.]

As mentioned previously, Eclipse 3.0 is all built on OSGi bundles. And, as they're available with source code, they provide numerous examples of fairly complex bundles.

The OSGi standard is technically known as the OSGi Service Platform, Release 3.0. Unfortunately, the 600-page document (available for no cost on the OSGi website) is more of a specification than a tutorial. Release 4 is currently under development, and is expected to provide even better support for desktop applications, now that Eclipse has firmly anchored the framework there. Until that release is available, sometime in 2005, I suggest using the tutorials and aids listed in "OSGi Resources."

A Note About Eclipse
Eclipse is a radical implementation of the plug-in concept. Like many OSGi applications, it starts off setting up the framework and then relies on bundles for all functionality. Even though Eclipse 3.0 is the first release of the IDE to use OSGi, plug-ins developed for previous releases work just fine on it due to a backward-compatibility layer provided by IBM that works with "99 percent" of previous plug-ins. This layer is located in the org.eclipse.core.runtime.compatibility_ 3.0.0 directory of the Eclipse distribution. Developers who want to continue using the 2.x plug-in model should do so without fear of incompatibility, although eventually, I suspect, Eclipse will deprecate the 2.x interfaces.

Andrew Binstock is the principal analyst at Pacific Data Works LLC, which publishes technical white papers. Previously, he was in charge of global technology forecasts for PricewaterhouseCoopers. Earlier, he was the editor in chief of UNIX Review magazine. His book Practical Algorithms for Programmers is currently in its 14th printing at Addison-Wesley. He can be reached at [email protected].