OSGi in a nutshell


This section gives a very brief presentation of OSGi. More information can be obtained from the OSGi specification.

OSGi specification

The Open Services Gateway Initiative OSGi is an independent, non-profit corporation working to define and promote open specifications for the delivery of managed services to networked environments, such as homes and automobiles. These specifications define the OSGi Service Platform, which consists of two pieces: the OSGi framework and a set of standard service definitions. The OSGi framework, which sits on top of a Java virtual machine, is the execution environment for services. The OSGi framework was originally conceived to be used inside restricted environments, such as the set-top box in figure 1. OSGi can however be used in other domains, as for example, an infrastructure to support underlying release 3.0 of the eclipse IDE.


Figure 1. OSGi overview

The OSGi framework

The framework can be divided in two main elements:

Services Platform

A services platform is defined as a software platform that supports the service orientation interaction depicted in figure 2. This interaction involves three main actors: service providers, service requesters and a service registry, although only the service registry belongs to the services platform. In the service orientation interaction, service providers publish service descriptions, and service requesters discover services and bind to the service providers. Publication and discovery are based on a service description.


Service Interaction

Figure 2. Service orientation interaction

In the context of OSGi, a service is described as a Java class or interface, the service interface, along with a variable number of attributes, the service properties, that are name and value pairs. Service properties allow different service providers that provide services with the same service interface to be differentiated. The service registry allows service providers to be discovered through queries formulated in an LDAP syntax. Additionnaly, notification mechanisms allow service requesters to receive events signalling changes in the service registry; these changes include the publication or retrieval of a particular service.

In OSGi, service providers and requesters are part of an entity called a bundle that is both a logical as well as physical entity. Service interfaces are implemented by objects created by the bundle. In standard OSGi, the bundle is responsible for run-time service dependency management activities which include publication, discovery and binding as well as adapting to changes resulting from dynamic availability (arrival or departure) of services that are bound to the bundle.

Deployment infrastructure

Physically, a bundle correspond to a delivery and deployment unit that is materialized by a JAR file that contains code and resources (i.e., images, libraries, etc.) along with a file that contains information about the bundle, the manifest file. The OSGi framework provides mechanisms to support continuous deployment activities (for example a local console or an administration web page). These deployment activities include installation, removal, update, starting (activation) and stopping (de-activation) of a physical bundle. Once a bundle is installed in the platform, it can be activated if deployment dependencies that are associated to the bundle are fulfilled (these dependencies are described in the next section).

Figure 3. Physical bundle life-cycle


Deployment activities are realized according to a well defined series of states depicted in Figure 3; these states correspond to the physical bundle life-cycle. The activation or de-activation of a physical bundle results in the creation or destruction of a unique logical bundle, materialized by an instance from a class inside the bundle called a bundle activator. When the instance is created, the execution environment calls an activation method that signals the logical bundle that it is active. When the physical bundle is de-activated, the execution environment calls a de-activation method. When the logical bundle is active, it can publish or discover services and bind with other bundles by accessing the framework's services registry. It can also be notified from changes that occur in the framework by subscribing as an event listener.

A better understanding of OSGi can be achieved by following this tutorial.


Last revision : 01 March 2004
 
(c) H. Cervantes and R.S. Hall

Next : Dependency management

Index