The OSGi - Open Service Gateway Initiative

a quick technical description

I have mention before the case of OSGi, mainly when referring to ServiceMix4 case. Although, the main idea was expressed there, I was probed for a little (and short) deeper description. 

Overview

First of all it must be stated that, OSGi is a specification of a service platform in Java, e.g. OSGI runs on top of a Java Runtime environment. The core of OSGi defines a component and service model. This component model allows to activate, de-activate, update and de-install existing components and services and to install new components / services dynamically.

The smallest unit of modularization in OSGi is a bundle. OSGi defines a registry which bundles can use to publish services or register to other services.

OSGI has several implementations, for example Knopflerfish OSGI or Apache Felix. For those bundled into Eclipse, the latest Eclipse Equinox is currently the reference implementation of the OSGI specification.

Eclipse Equinox is the runtime environment on which the Eclipse IDE and Eclipse RCP application are based. In Eclipse the smallest unit of modularization is a plug-in. The terms plug-in and bundle are interchangeable. An Eclipse plug-in is also an OSGi bundle and vice versa.

The OSGI bundles

OSGI bundles are .jar files with additional meta information. This meta information is stored in the manifest.mf file.

Via this manifest.mf a bundle can define its dependency to other bundles and services and can also restrict the Java classes which should be available to other bundles. This restriction is done based on the packages name. This restriction is enforced in OSGi via a special Java class loader. Access to the restricted classes is not possible, also not via reflection.

OSGI services

A bundles can register and use services in OSGI. OSGI provides therefore a central registry for this purpose. The power and one of the most promising points of OSGi approach, is that a service is defined by a Java interface (POJI - plain old Java interface).

Access to the service registry is performed via the class BundleContext. OSGI injects the BundleContext into each bundle during the startup of the bundle. A bundle can also register itself to the BundleContext ServiceEvents which are for example triggered if a new service is installed or de-installed.

OSGI dependency management

OSGI is responsible for the dependency management between the bundles. These dependencies can be divided into:

1. Bundle (Package) Dependencies
2. Service Dependencies

OSGI reads the manifest.mf of a bundle during the installation of the plug-in and ensures that all dependent bundles are also loaded if the bundle is activated. If the dependencies are not meet then the bundle is not loaded. Bundle / package dependencies are based on dependencies between standard Java objects and in case OSGI can not resolve all dependencies this results in a ClassNotFoundException.

As service in OSGI can be dynamically started and stopped, therefore the bundles must manage these dependencies themselves. The bundles can use the service listeners to get informed if a services is stared or stopped.

 

This is the high level technical knowledge that an intro can be of use before using, installing or adopting the OSGi approach. From this point and on, use the Eclipse, or Felix or Knopflerfish or…  approaches suites to you.