[RFC 112][repository] define a capability namespace for services

[bjhargrave]

Original bug ID: BZ#2246 From: @tjwatson Reported version: R5

[bjhargrave]

Comment author: @tjwatson

We have moved bug2081 to a future specification, but we still need to define a namespace for services so there is a standard way to express the service capabilities and requirements in a Repository.

[bjhargrave]

Comment author: @tjwatson

A simple approach would be to use the service properties as capability attributes for the namespace (including objectClass). We also need to pick a name for the services namespace. I consider the objectClass attribute is considered the primary key for the namespace. Past convention was to make the primary key the name of the name space (e.g. osgi.wiring.package name space). Using that convention we would either need to use objectClass as the name space, or replace the usage of the objectClass attribute name with something else, or decide to break the convention for this namespace.

For the initial proposal I am going to suggest we break with the convention. The suggested name of the name space is "osgi.service". For example, using the Repository exchange XML format:

<capability namespace='osgi.service'>
  <attribute 
     name='objectClass' 
     value='com.watson.CoolService' />
  <attribute value='1.0' name='version' type='Version' />
</capability>

Note that we are limited to the following types according to the initial spec chapter of RFC 112:

”String” | “Version” | ”Long” | ”Double” | “List” | “List” | “List” | “List”

Declarative Services supports these property types:

String, Long, Double, Float, Byte, Character, Boolean, Short

Initial thinking is that most of these can be converted into the limited supported types in 112 (except Boolean):

String -> String Long -> Long Double -> Double Float -> Double Byte -> Long Character -> String ?? Boolean -> ?? Short -> Long

I am not familiar with all the types blueprint supports or how limited we will be with the limited types supported in the exchange format of a Repository.

[bjhargrave]

Comment author: @bosschaert

I like the proposal and am in favor of the osgi.service->objectClass combination. However regarding other service properties. In some cases these can change frequently, e.g. think about a ManagedService where the convention is to have the service properties match the supplied configuration. So I think we can never have a situation where a Repository contains all service properties associated with a service. Although there should be the option to register some 'permanent' properties associated with the service.

WRT to Boolean and Character. I think it would be useful to add Boolean to the upcoming Repository spec. Not sure how valueable Character is... I guess we could add that one too.

[bjhargrave]

Comment author: @tjwatson

Moving to CPEG since this namespace will need to be added to the new org.osgi.framework.namespace package.

[bjhargrave]

Comment author: @bjhargrave

Boolean -> ??

CPEG mtg: We agreed to map Boolean to a String of either "true" or "false".

[bjhargrave]

Comment author: @bjhargrave

I released ServiceNamespace to the org.osgi.service.repository package. It is a subtype of the core AbstractNamespace type.

Reassigning bug back to EEG since the ServiceNamespace is part of the Repository spec.

[bjhargrave]

Comment author: @pkriens

This Service Namespace should not go to into the repository service package since it has no affinity with the repository.

If the Service Namespace implies a dependency on a bundle POTENTIALLY registering this service then I think it should go into the core org.osgi.framework.namespace package since it then bases it on the existing semantics. These would be similar to the deprecated Import-Service/Export-Service headers. The contract would still require DS or Blueprint or manual work to handle the dynamic part of the services. In this case it is there to get an early message for a bundle that is eagerly waiting through DS for a USB Service but there is no driver installed that could even register it. Bindex et. al. can then use this namespace to create entries in the repo xml.

However, if the intention is to handle the dynamic aspect of services then I think we should bail on this because this require a new effective time and for that time is too short.

[bjhargrave]

Comment author: John Ross <jwross@us.ibm.com>

However, if the intention is to handle the dynamic aspect of services then I think we should bail on this because this require a new effective time and for that time is too short.

I thought this was the intention and that we already had a new effective time of ACTIVE?

[bjhargrave]

Comment author: @tjwatson

This Service Namespace should not go to into the repository service package since it has no affinity with the repository.

If the Service Namespace implies a dependency on a bundle POTENTIALLY registering this service then I think it should go into the core org.osgi.framework.namespace package since it then bases it on the existing semantics. These would be similar to the deprecated Import-Service/Export-Service headers. The contract would still require DS or Blueprint or manual work to handle the dynamic part of the services. In this case it is there to get an early message for a bundle that is eagerly waiting through DS for a USB Service but there is no driver installed that could even register it. Bindex et. al. can then use this namespace to create entries in the repo xml.

This is the intention. It is meant to be used so the repo xml can express the service dependencies that something like Bindex et. al may have found by parsing other metadata in the bundle (DS, blueprint, iPOJO etc.). It could be used in a bundle manifest if a developer really wants to, but this is not the usecase we had in mind for this namespace.

However, if the intention is to handle the dynamic aspect of services then I think we should bail on this because this require a new effective time and for that time is too short.

This is not the intention.

[bjhargrave]

Comment author: @tjwatson

This Service Namespace should not go to into the repository service package since it has no affinity with the repository.

BJ and I did discuss this some. I thought it made sense in the repository package simply because the intention is that this namespace would only be used by a resource contained in a repository.

[bjhargrave]

Comment author: @bjhargrave

BJ and I did discuss this some. I thought it made sense in the repository package simply because the intention is that this namespace would only be used by a resource contained in a repository.

It is my belief that this namespace is for deployment time. That is, adding a bundle to a repository means the repository will crawl the bundle (manifest, DS XML, blueprint XML, etc.) for interesting capabilities and requirements. Then management agents can search the repository based upon this information.

I do not feel that this namespace is for runtime use at all. Certainly not as a resolve time thing because services are (1) only at active time and (2) highly dynamic in that being active does not mean a bundle either provides or consumes some service.

Based upon this, I do not think this namespace is part of the core spec in any way. And I also see that this namespace could be part of the repository spec since it is the repository that indexes this information out of the bundle upon addition to the repository.

So, in summary, this namespace cannot be in the Core R5 spec. It is too late to add it and resolve any issues regarding potential use as a resolve time or an active time (which is not even a time defined in the core spec for namespaces). It can be in the Enterprise R5 spec if we agree on a home. Or we can drop it from R5 until we figure it out more fully.

[bjhargrave]

Comment author: @bjhargrave

CPEG call: Agreed to create a new org.osgi.namespace project to host namespaces which are not directly used by Core. The ExtenderNamespace, ContractNamespace and ServiceNamespace will be moved into this new project.

Peter will create a new chapter to be included in Compendium and Enterprise to specify these namespaces.

Assign to BJ to create the new project.

[bjhargrave]

Comment author: @bjhargrave

Release the org.osgi.namespace project

https://www.osgi.org/members/gitweb/build.git/commit/e918bc070e398b7ebaa1386e92bb0b7ccbdcd40f

Assign to Peter to create new spec chapter for Enterprise spec.

[bjhargrave]

Comment author: @bosschaert

In Enterprise R5 draft.