The Service Controller

The IServiceController interface and its implementation ServiceController are the core pieces of the framework and responsible for service discovery, lifecycle and dependency management

IServiceController extends IServiceAvailibillityListener and the implementation must implement the provided methods by that interface. The implementation must track all available services implementing IServiceDescriptorRepository at runtime. The implementation must further register itself as ServiceAvailibilityListener with these IServiceDescriptorRepositories. Whenever services become available they enter the service lifecycle described in the next section.

We distinguish 2 states for ServiceDescriptors

• the INSTALLED state: A ServiceDescriptor is in the installed state, if it is available in exactly one IServiceDescriptorRepository and recognized by the IServiceController implementation.
• the RESOLVED state: A ServiceDescriptor is in the resolved state if it is INSTALLED and all Dependencies are resolved. A Dependency is resolved, if one or more ServiceDescriptor instances describing the required service are available and at least one of them is in the RESOLVED state.

We distinguish 2 states for ServiceInstances

• the INACTIVE state, A ServiceInstance is initially in the INACTIVE state. In this state not all dependencies are resolved and the service object is not registered with the corresponding BundleContext. The controller must activate ServiceInstances in the INACTIVE state whenever possible.
• the ACTIVE state A ServiceInstance is in the ACTIVE state when all dependencies are satisfied and if it is registered with the OSGi framework.

Furthermore, we notice the following transitions between these states:

• Discovery: As soon as a ServiceDescriptor becomes available it enters the INSTALLED state.
• Resolution: The framework tries to resolve services in the INSTALLED state. During resolution, the framework tries to locate ServiceDescriptors matching the declared dependencies of a particular service. If such descriptors can be found and are themselves in the RESOLVED state, we consider the dependencies resolved . In a second phase the framework locates ServiceDescriptor which depend on the freshly discovered ServiceDescriptor and updates their dependencies.
• Instantiation: ServiceDescriptors in the RESOLVED state it can be instantiated and returns a fresh ServiceInstance. This instance enters the INACTIVE state.
• Activation: If all dependencies can be satisfied, the service enters the ACTIVE state. In this state it is fully functionable. Only services in the ACTIVE state must be used by other services.
• De-activation: A "initiated transition" form the ACTIVE state to the INACTIVE state occurs when the IServiceController is advised to shutdown (unregister) this service. This transition signals to dependent services that the service is about to become unavailable. A service in the ACTIVE state enters the INACTIVE state when one of the services it depends on enters the INACTIVE state. We call this a "propagated transition". If this is the case the IServiceController attempts to re-satisfy this particular dependency.

The two main extension points are the IServiceConfigurator and IServiceDescriptorRepository interfaces. A IServiceConfigurator implementation represents a strategy in dependency election of ServiceInstances. See setServiceConfigrurator(IServiceConfigurator)