OSGi is a hardware-independent, dynamic software platform that simplifies the process of modularizing distributed applications and their services, and managing them throughout their entire life cycle (Wütherich et al. 2008). The OSGi platform requires a Java Virtual Machine (JVM) and provides a framework on the basis of the JVM. The OSGi alliance (Open Service Gateway initiative) is an industry consortium consisting of a number of manufacturers from different sectors, which originally developed the platform for use in embedded systems. The most important features of OSGi are as follows:

The specification of the OSGi service platform defines a runtime environment (container) based on a Java Virtual Machine (JVM). One of the important enhancements is the option of equipping the software bundles with independent class loaders and, therefore, running different versions of the same software in parallel on the same JVM. In addition, the OSGi container gives the bundles their own service life cycle, which enables services to be installed, started, stopped, removed, and updated at runtime. Both these factors—versioning and life cycle—are of particular interest in productive environments where high levels of availability are needed. OSGi is therefore ideal for integrating embedded systems, for example, as there is no maintenance window needed for upgrading components.

OSGi has published 4 specifications. The majority of OSGi implementations are based on the release 3 specification from 2003 (OGSi 2003). Well-known implementations include the Eclipse 3.0 platform (Gruber et al. 2005) and the "software in the car" platform developed by BMW (Saad 2003) and Daimler (Heinisch, Simons 2004). As of October 2009, there are five certified OSGi implementations for release 4.

The architecture of the OSGi service platform enables a range of independent service modules to be run in parallel on the same JVM and allows them to be monitored, managed, and updated throughout the entire software life cycle, as shown in the preceding diagram. Remote maintenance is also possible. The interdependencies of bundles are resolved and managed by the OSGi container. The implementations and products that are currently available consist of the OSGi framework and a number of existing software bundles, which, because of their modular structure, can be dynamically added to or removed from a runtime environment.

The current OSGi specification focuses on the component, which is packaged as a bundle. A compoment can publish its interface using the service registry and make it available for use. Components of this kind have a monitored life cycle with options for (re)deployment.

The OSGi framework covers the following points:

OSGi architecture

The most important layers of the OSGi architecture are the execution environment, modules, life cycle management, and service registry, as shown in the following diagram:

Let's have a look at these layers one by one:

• Execution environment: A Java environment, such as J2SE.
• Modules: All the classes and resources grouped together as bundles. A bundle can include entire applications, parts of applications, individual service components, and entire libraries. The starting point at runtime is the OSGi system bundle, which makes the OSGi software infrastructure available.
• Life cycle management: A defined life cycle for each bundle in the form of an API. This API has the following life cycle statuses, as shown in the following diagram:
  • install
  • resolve
  • start
  • stop
  • refresh
  • update
  • uninstall
    
• Service registry: The management of all services. This includes identifying services on the basis of their interface definition or properties, and sending notifications between services. It also involves binding to one or more services using program controls, pre-defined standard behavior rules, and distribution configurations.

OSGi bundles

The OSGi component model consists of bundles. These are services, which are managed in a service registry. However, the OSGi service is nothing more than the general interface concept of a software component. It defines a decoupled component model that supports the reusability and the use of small components.

A bundle represents an application deliverable, which is similar to an application executable, in the form of a JAR file. A bundle registers one or more services. A service is specified in a Java interface and can be implemented by several bundles. Services are bound to the bundle life cycle. A query language can be used to search for services registered by other bundles.

A bundle contains program code, additional resources (optional), and a manifest file that defines the bundle context. The OSGi framework reads the manifest and installs the code and resources in the OSGi runtime environment on this basis. Dependencies with other bundles and services are also resolved using the information in the manifest. At runtime, the framework starts the bundle via the bundle activator and manages the class path and the dependencies (references to other bundles and services). The framework can also stop a bundle by means of the bundle activator.