Service components

The ServiceBinder introduces the concept of service component to the OSGi framework. A service component is similar to the concept of a logical bundle but the difference is that multiple service components can be deployed inside a single physical bundle.

A service component (see Figure 1) declares a set of provided service interfaces, and a set of required service interfaces. During execution, an instance of a service component implements the provided services and is connected to other instances to create an application. Service properties identify the instance and are used when its services are published in the service registry.

Fig 1. A component class

Provided and required service interfaces along with service properties represent an external view for the component and are part of the application logic. This external view is implemented by a component implementation that can also provide certain control interfaces and have some dependencies. Control interfaces implement the inversion of control pattern and are provided so that the execution environment can manage instance's lifecycle. Implementation dependencies represent dependencies from the component implementation on ressources that are delivered along with the component (such as libraries or binary files) or they represent deployment dependencies.

Dependency properties

Service components do not need to contain any service dependency management logic, as this logic is contained inside the execution environment of the component model. Service components must, however, provide informations that configure the service dependency management logic. This information is attached to required service interfaces as a set of dependency properties that include cardinality, policy and a filter.

cardinality: defines both the optional character of a binding and the number of bindings that are created at run-time between a particular component instance and other instances. A binding is either optional or mandatory and simple or multiple.

policy: defines if a bindings can change during execution. Changes include the creation of new bindings or the destruction of existing bindings.

filter: allows to narrow the selection of service providers that can be used when a binding is created.

Service component description

Service components are described inside an XML file called a component descriptor (see: descriptor DTD), which is contained inside the physical bundle and can be seen as an extension to the bundle manifest file (the location of the component descriptor is given inside the manifest through the key Metadata-Location). Inside this descriptor, components are declared as shown in figure 2. A bundle can contain several components.

<?xml version="1.0" encoding="UTF-8"?>
<bundle>
<component class="org.simpleclient.impl.ServiceImpl">
    <provides service="org.simpleclient.interfaces.SimpleClientServiceA"/>
    <provides service="org.simpleclient.interfaces.SimpleClientServiceB"/>
    <property name="provider" value="Beanome.org" type="string"/>
    <requires
        service="org.simpleservice.interfaces.SimpleService"
    filter="(version=*)"
        cardinality="1..n"
        policy="static"
        bind-method="setServiceReference"
        unbind-method="unsetServiceReference"
    />
</component>
</bundle>

Figure 2. Example component descriptor file.

The different tags that can be used in the component descriptor are:

<bundle>

Tag that delimits the set of components contained inside a physical bundle. Several components can be declared for one bundle.

<component> (was <instance> in version 1.0)

Defines a class that implements the component. This class must implement all the provided service interfaces.

<provides> [optional] (was<service interface="..."> in version 1.0)

One of these tags must be included for each service interface that the instance implements. If at least one these tags exist, it will result in a service registration for the defined service interfaces.

<property> [optional]

One of these tags must be included for each service property. If a <provides> tag is present, the properties will used during service registration. The description of a property includes its name, value, and type (supported types are: string, boolean, byte, char, short, int, long, float, double).

<requires> [optional]

One of these tags must be included for each of the instance's service dependencies. The properties of this tag are:

service: the fully qualified interface name of the required service.

filter: a filter to narrow the search (in LDAP syntax).

cardinality: cardinality can take the following values: 0..1, 0..n,1..1, 1..n the lower end represents optionality (0 - optional, 1 - mandatory) and the upper end represents multiplicity (1 - single binding, n - multiple binding)

policy: static or dynamic (see : Instance management)

bind-method: The name of the method that is called on the implementation object when a service is connected to it. Note that this method receives as a parameter the service object itself and not the OSGi service reference.

unbind-method: The name of the method that will be called on the implementation object when a service is disconnected to it. Note that this method receives as a parameter the service object itself and not the OSGi service reference.

Last revision : 04 February 2004
(c) H. Cervantes and R.S. Hall

Next : Instance Management

Previous : Dependency Management

Index