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, if inside its implementation it uses services to accomplish a particular goal. During execution, instances of these components implement the provided services and are connected to other instances to create an application.

Fig 1. A component class

Provided and required service interfaces along with service properties are part of the application logic. Control interfaces are necessary for the execution environment to manage instance's lifecycle and implementation dependencies represent dependencies from the component implmentation on ressources such as libraries or binary files (images, etc...).

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 and the number of bindings that are created at run-time between a particular component instance and other instances. A requires service interface can be declared as being optional or mandatory and being 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 1. 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 1. 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: 0..1, 0..n, 1..1,1..n (see: Instance management)

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