Introduction to the OSGi Environment

The OSGi Platform is a componentization layer to the Java Virtual Machine. It supports the runtime extension of Java-based application through a modular approach: the applications are parted into `bundles', that can be loaded, installed and managed independently from each other.

An overview of the OSGi Platform is first presented, then the core concept of OSGi: the bundles and their Life-Cycle, and the possible interactions between them.


The OSGi Platform has been developed so as to support extensible Java-based systems in resource-constraint systems, such as automotive and mobile environments. It has since then spread into the world of Integrated Development Applications (in particular with Eclipse), and into applicative servers (IBM Websphere 6.1, Harmony, Cocoon, Directory...).

It runs as an overlay to the Java Virtual Machine (JVM). The next figure shows the overview of an OSGi-based system, with the Operating System (OS), the JVM, the platform itself, and the bundles it contains.

Overview of an OSGi Platform

Three main concepts sustain the OSGi platform: the platform, the bundle, and the interoperability between the bundles. The Platform manages the applications. The bundles are the unit of deployment and execution. The interoperability between the bundles is achieved at the class level (access to packages from other bundles) and at the service level (access to services registered by other bundles).

The Bundles

An OSGi bundle is a Jar file which is enhanced by specific meta-data. The typical structure of a bundle is shown in the next Figure. The META-INF/MANIFEST.MF file contains the necessary OSGi meta-data: the bundle reference name (the `symbolic name'), its version, the dependencies and the provided resources. Some packages are exported, i.e. accessible from other bundles inside the platform. The activator is used by the platform as an initial bootstrap when the bundle is started. Packages can be exported. Services can be registered, so as to be available for other bundles.

Intern Structure of an OSGi bundle

Each bundle has a restricted view on the OSGi platform: the OSGi Context, which is transmitted to the bundle activator at start time. This context reference is needed to publish and look-up for services. It also supports the access to the management functionalities of the platform.

The OSGi bundles can also access the Operating System of the machine it is running on through native libraries. This possibility is not specific to the OSGi environment, since it relies on the Java Runtime API, but it allows the bundles to break their isolation.

The Life Cycle of a bundle inside the OSGi Platform is defined as follows. The bundle must first be installed. When it is required to start, the package-level dependencies with other bundles are resolved. When all dependencies are resolved, the bundle activator is launched: the start() method is called, and the related code is executed. Typically, these operations consist in configuration and publication of services.

The bundle is then in the `started' state. Updating, stopping and uninstalling build the last possible operations for bundle management The next figure shows the Life Cycle of a bundle inside a OSGi Platform.

Life Cycle of an OSGi Bundles inside the platform

Interactions between Bundles

The interactions between the bundles are done through two complementary mechanisms: the package export/import and the service registration lookup facility. These mechanisms are shown in the next Figure.

Interaction Mechanisms between the OSGi Bundles

The publication and lookup of services are performed through the BundleContext reference that each bundle receives ar startup time. During the publication process, the advertising bundles registers a service by publishing a Java interface it is implementing, and by providing a class implementing this interface. The lookup is performed by the client bundle, which gets the service from the BundleContext and uses it as a standard Java object.