Provided Service Handler

This handler allow a component to publish an OSGi service. It manages:

• the service publication
• the component instance / service object creation
• the service unregistering

The provided service handler manage provides element. Each provided element represent a provided service.

Provided Service

The provided service element manage the service publication and providing. It manages the service property too. Therefore, when service properties change dynamically, it needs to update the service registration... Provided services follow the component state: when the component becomes invalid, the provided service need to remove the service registration from the registry.

Metadata

The following UML class shows the element composing a provided service. You can see that service properties are attached to a provided service. Some of these attributes are optional ([0..1]). Indeed, either the component code contains the information; either iPOJO uses default behaviour.

The provided service class contains no mandatory attribute. Interface contains the service interface. If no specified, the provide service provide a service exposing all the implemented interface of the component.

Note : if the component implements several interface, the provided service expose an class array containing all these interfaces

The factory attribute is optional. It describes the policy to create the service objects (i.e. component instance). iPOJO supports two different factory policies: SINGLETON (default) and SERVICE. The singleton policy returns always the same component instance to each client. The service policy follows the OSGi service factory policy: returns one different object per requester bundle.

A provided service can be specialized with properties. Thises properties could be attached to a component field.Properties without a field attribute cannot change dynamically. The component metadata contains the constant value of the property. The property name and type are used for the service publication and for the service filter.
Properties with a field attribute own a link with the component implementation. It reflects a field of the component class. Thus, the component class can change the service value. The name of the field is mandatory, but the two others attribute are optional. If the metadata does not contain a property name, the field name is used as property name. The value attribute allows metadata to fix a value to the property before the first service object instantiation. Indeed, if the component metadata does not contain a value, and if no service objects are created, the property value has no value. iPOJO choose to hide a property without a value.

XML Metadata

<Provides interface="fr.imag.adele.escoffier.hello.HelloService" factory="SERVICE">
<Property type="java.lang.String" name="Provider_Name" value="Clement"/>
<Property name="language" value="fr" field="language"/>
<Property name="floorProperty" field="floor"/>
</Provides>

<Provides/>

Manifest Metadata

Provides { $interface="fr.imag.adele.escoffier.hello.HelloService" $factory="SINGLETON"
Property { $type="java.lang.String" $name="Provider_Name" $value="Clement" }
Property { $name="language" $value="fr" $field="language" }
Property { $name="floorProperty" $field="floor" }
}

Provides {}

Perspectives

We are thinking about different perspectives. Concerning the build policy, other policies like pool could be benefit. An enhancement of the property could be benefit too. Nevertheless, our main interest way concerns the improvement of the service specification (interface today).Some research work improve interface to contains otherinformation like state, service dependency, mandatory properties ...