Startup Order Resolving Mechanisms in OSGi
There are few mechanisms in OSGi to deal with the bundle startup order. Most obvious approach is to use “start levels”. The other approach is to use OSGi services to order the initialization of bundles or modules. Declarative services make it easy to deal with OSGi services. Following sections describe these approaches in detail.
Lets consider a sample OSGi-based system. This system contains two modules called, Microservice manager and Transport manager. Microservice manager (Bundle) is responsible for deploying microservices available in bundles. Bundles register microservices as OSGi services. When microservice manager deploys all such services, we need to start all the available transports in the system. This task is handled by the Transport manager. Bundles register transports as OSGi services. Transport manager start all such transports. Starting a transport means opening a port and make the server ready to serve requests to microservices. In order to make this system work, microservice manager has to be initialized first before the transport manager. Otherwise transports will be started first, but the server is not ready to serve requests. Likewise there can be many cases where we need to carefully handle to startup order of OSGi modules.
Start levels
The OSGi framework has introduced a concept called ‘start levels’ to an OSGi bundle. Start levels help you to start your bundles in a predefined order. The usage of this start levels concept can cause problems in the latter stages of your application development. You may find it difficult to perform debugging and also introducing new bundles can break the existing startup order of your old bundles. In such situations, you have to re-arrange the startup order.
OSGi services
OSGi services offer you a reliable way to resolve the dependency/module startup order. As an example, if bundle ‘A’ registers an OSGi service when it becomes fully initialized, then bundle ‘B’ can hold its initialization until the OSGi service from bundle A is available. Likewise, you can think of a solution to resolve the order. However, you cannot easily implement this behavior using OSGi Service APIs such as ServiceListeners, ServiceTrackers etc.
Declarative services
The declarative services specification allows you to publish and consume OSGi services declaratively and more importantly without using any OSGi service APIs. This specification introduces a concept called “service component”, which can publish as well as consume OSGi services. Also, these components can declare start/stop or activate/deactivate methods and these methods will be invoked when all the service dependencies of a service component are satisfied.
When you declare an OSGi service requirement, you can specify whether a service is a mandatory service or an optional service (i.e. the cardinality of a service). If there are three mandatory services declared in a component, its ‘activate’ method is invoked only when all three services are available. Thereby, you can use declarative services to order the module startup in OSGi applications.
The availability of the optional services does not affect component initialization. Service component will be notified when optional services become available even after the service component has been initialized. Following are the possible values that you can specify for the cardinality:
Now with OSGi services and declarative services, we can order the initialization of microservice manager and transport manager.
But OSGi services and declarative services cannot solve all the startup order related issues in OSGi based systems. I will explain this via another post. We’ve experienced this while developing WSO2 Carbon and Carbon based products. In Carbon we’ve heavily used OSGi services to order the initialization of modules or Carbon components (Carbon component can be considered as a set of logically related bundles).
