Figure 1. An OSGi application
Dependency management in OSGi occurs at two different levels, at the physical-bundle level and at the logical-bundle level:
At the physical-bundle level, dependency management involves deployment dependencies.
At the logical-bundle level, dependency management involves service dependencies.
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. 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.
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.
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.
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.