SCR Service

Provides information on an implementation of the Service Component Runtime according to the OSGi Declarative Services Specification Release 6.0.

Overview

The specification defines a declarative model of using OSGi services that allows to delay the creation of the service object until the moment it is actually used. Using the declarative services model provides the following benefits:

• Delayed creation of service objects and their class loaders.
• Reduced startup time and memory footprint.
• Low resource requirements as the model is applicable on resource constrained systems.
• Simplified mechanism for authoring services.
• Simplified programming model provided by a lightweight API.
• Decreased amount of required code.

Registering Bundle

The service is registered by OSGi SCR Bundle.

Service Component

The declarative services model defines a service component as main unit for manipulating with OSGi services functionality.

A service component is an entity consisting of a Java class and its XML description, which can register or reference a service in a lazy fashion. Both, service component's Java class and its description are packed in a bundle that is deployed in the OSGi framework where it functions like any traditional OSGi bundle.

A service component has the following features:

• Its lifecycle is contained in its bundle's lifecycle.
• It is uniquely identified by its implementation class.
• It can provide services to the OSGi framework.
• It can reference services provided by other components and traditional OSGi bundles in the framework.
• It can be configured through the OSGi Configuration Admin service.

A service component will be referred to as component and its XML description as component description from now on in this document.

Service Component Runtime

The Service Component Runtime (SCR) is the module that manages the components and their lifecycle. It performs the following functions:

• Track component dependencies and manage their dynamics.
• Activate the component when its dependencies are met.
• Publish the component in the service registry on its activation.
• Create the component instance when the component is going to be used.
• Dispose of component instances when they are no longer used.

Component Context

A component can receive its Component Context through its activate method. A Component Context can be used to locate services referenced by the component, or to enable or disable components from the same bundle.

Component Description

The declaration of a component in an XML format is the component description. It uniquely identifies the component to the SCR and provides information about the component's functionality that will be used by the SCR to perform its management operations.

The component description provides information about:

• The name of the component
• The name of the Java class implementing the component
• The Services provided by the component
• The Services referenced by the component
• The Configurable properties of the component

Component Factories

The declarative services model supports creating multiple instances of the same component type in compliance with the Service Factory concept in the OSGi framework.

Multiple instances of the same component type can be created by:

• A Component Factory service – It is registered as an OSGi service by the SCR and it can create multiple instances of a component.
• A Managed Service Factory – If defined in a Configuration Metatype XML, the SCR can produce a Managed Service Factory for a component with a set of properties. For each newly created configuration instance from the SCR-provided Managed Service Factory, the SCR creates a new component instance. If the component registers a service, for each component instance a new service object will be created with property values taken from the configuration instance.
• A Service Factory – A component can be declared in its description to use a Service Factory without need to implement an org.osgi.framework.ServiceFactory. It will produce new instances of the component for each referencing bundle or component. The properties of the service provided by the component will be the same for all newly produced component instances.

A component cannot be declared as a factory component and use a Managed Service Factory and Service Factory at the same time. You have to choose only one of these factories to produce new instances of the same component type.

Component Properties

A component can have a set of properties specified in three places in the following order of precedence:

• Properties passed to the Component Factory service when creating new instances of the same component type.
• Properties retrieved from the Configuration Admin service.
• Properties specified in the component description. In the case of a service-providing component, they are exported as properties of the registered service with specific default values. The values of these properties can be overridden through the Configuration Admin service or by passing new property values to the newInstance method of the Component Factory service.

Each component also has COMPONENT_NAME property defined in its description and COMPONENT_ID property given by the SCR.

The COMPONENT_NAME and COMPONENT_ID properties are obligatory and their values cannot be overridden as they uniquely identify the component to the SCR.