Dependency management

Dependency management in OSGi occurs at two different levels, at the physical-bundle level and at the logical-bundle level:

Deployment dependency management

Deployment dependencies occur when code not contained in a particular bundle JAR file is required by the classes contained inside the bundle. In this case, the bundle must declare explicitly that this code is imported from another bundle (as a Java package). Other bundles, that explicitly export certain Java packages, can satisfy these import requirements. Imported packages must be present to allow a physical bundle to be activated. Code dependencies are declared in the manifest file inside the Jar file, and are managed by the framework.

Service dependency management

Service dependency management includes all the activities necessary to create binding between logical bundles during execution. This includes service publication, discovery, binding and adaptation with respect to changes due to dynamic availability (the arrival or departure) of services that are being used by a bundle during execution. Service dependency management is the key to building applications for the OSGi framework. Unlike code dependencies, service dependencies are not guaranteed, or managed, by the framework; this means that a physical bundle can be activated, even if services required by the logical bundle are not available. Service dependencies can be declared in the manifest file, but currently the OSGi specification indicates that they are declared for information purposes only. 

Figure 1. An OSGi application

Figure 1. depicts a typical OSGi application modeled as a series of logical bundles that are connected through provided and required services. Sensor bundles are connected to physical sensors such as motion detectors, smoke detectors or cameras. A monitor polls the sensors and responds to particular situations for example by sending an e-mail to an administrator or by writing a log. The monitor also uses the services provided by an HTTP server to register a servlet so that management can be done remotely through a web page.

In example above, the monitor's logical bundle uses services provided by other logical bundles to accomplish its task. In this case the monitor bundle is responsible for discovering the services it requires. On the other side, the logical bundles that provide services are responsible for publishing them in the service registry.

During execution, the different services exhibit dynamic availability as they are introduced or removed from the execution environment as a consequence of physical bundle deployment activities. It can be supposed, for example, that new sensor bundles can be introduced into the execution environment at any time, without the need of shutting down the system. Logical bundles are responsible for binding to newly arriving services or releasing departing services. Dynamic availability of services requires an application to be capable of dynamic assembly and dynamic adaptation.

Dynamic assembly

An OSGi application is assembled dynamically as the logical bundles that compose it publish their services and connect between each other. During assembly, logical bundles must be prepared to face the situation where some essential services are not present when they are activated. When this occurs, the bundles must enter an idle state where they wait for the services they require to become available.

Dynamic adaptation

Once an application is assembled and its execution has started, two situations can occur at the service level. The first is that services used by a logical bundle that composes the application are unregistered from the service registry, and the second is that new services that could be used by a logical bundle that composes the application are registered in the service registry. These two situations require that an application adapts itself. Adaptation requires two different activities to be realized: monitoring and reconfiguration.

The challenges of standard OSGi programming

Programming OSGi applications involves not only writing application logic but also writing service dependency management logic. This is a complex task that is further complicated by the fact that these two types of logic are often intermingled inside the classes contained in a bundle. This is precisely the problem addressed by the Service Binder, which is presented in the following sections.

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

Previous : OSGi in a nutshell