Information Technology Reference
In-Depth Information
Fig. 1.
Self
-OSGi System Diagram
5
Self
-OSGi Implementation
Figure 1 shows a diagram of the main classes involved in the operation of
Self
-OSGi,
including pre-existing OSGi classes, and few application components (
MoveTo
,
Laser-
SLAM
and
CameraSLAM
), extracted from a robotic example application.
With its declarative execution model, components are activated and deactivated un-
der the full control of the
OSGi Declarative Service (DS)
bundle. DS bases its decisions
on the information in the components definition stored in XML files, which describe the
services that are implemented by the component, and its dependencies on other services.
DS will automatically register every service provided by the component into the central
service registry of the platform, and bind every service required by the components with
those available in the registry.
If a components description specifies the
factory
attribute of the component element
in its XML definition, DS will register a
OSGi Component Factory
service. This service
allows client bundles to create and activate multiple components' instances, on demand,
and dispose of them after they have been used.
Self
-OSGi provides an explicit resolution service, which can be used explicitly by
application component plans to get the reference to the implementation of the service
goals they need. In the example, the service can be used to get a reference to an im-
plementation of the service goal
S
- representing any robot's localization system in the
example - to be called by the component plan
MoveTo
. Alternatively, the developer can
register the
OSGi Framework Find Hook Service
in order to be called during frame-
work service find (
getServiceReferences()
) operations. Noticeably, the latter approach
