[subsystems] Allow services to "punch through" an application subsystem scope

[bjhargrave]

Original bug ID: BZ#2506 From: Glyn Normington <gnormington@vmware.com> Reported version: R6

[bjhargrave]

Comment author: Glyn Normington <gnormington@vmware.com>

Walt Bowers (Chief Architect, OSGi Solutions, Hitachi Communications Technologies America, Inc.) asked me about a familiar use case for application subsystems at last week's EclipseCon, so I am logging it here for the record. His email address is Walt.Bowers@ hitachi-cta.com.

He wants a way for an application subsystem to expose one or more services -- nothing else -- externally to the application's scope.

We have seen this requirement before in Virgo and the solution there is to allow a service with a particular service property to "punch through" the scope provided by the scoped plan or PAR (Virgo's equivalents of an application subsystem).

Here's an extract from the Virgo Programmer's Guide:

[...] Services published by bundles in a scope are not visible to bundles in the global scope.

However, sometimes it is useful to make a service in a scope globally available to artifacts outside the scope. To do this, publish the service with the org.eclipse.virgo.service.scope service property set to global. Use the child element of , as shown in the following example:

[bjhargrave]

Comment author: Tim Diekmann <tdiekman@tibco.com>

Why wouldn't this be be possible by turning the application into a Composite?

[bjhargrave]

Comment author: Glyn Normington <gnormington@vmware.com>

Why wouldn't this be be possible by turning the application into a Composite?

That is a possible solution, but it lacks the simplicity of an application subsystem. I haven't looked into a suitable subsystem manifest, but would it be possible to export all services with a given service property with a fixed subsystem manifest as that could be sufficient?

[bjhargrave]

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

In section 3.9 of RFC 201 [1] but needs a technical solution.

[1] https://www.osgi.org/members/gitweb/design.git/blob/HEAD:/rfcs/rfc0201/rfc-0201-Subsystems-Update.pdf

[bjhargrave]

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

Perhaps a technical solution for this could be worked in as part of section 5.4 of RFC 201 where we are requiring subsystems implementations to honor the osgi.service namespace in the Provide/Require-Capability bundle headers. If any are declared, implementations must accept them as the final service policy of the bundle (i.e. no further computation of service capabilities/requirements for the bundle is done via Blueprint, DS, or whatever).

As suggested in comment 0, services that should "punch through" the application's sharing policy could be identified with a certain attribute or directive.

However, I'm sympathetic to comment 1. Basically, people want the convenience of computed headers for applications but with the ability make some tweaks. This could be done by tooling with the final product being a composite subsystem. I'm not sure where to draw the line between implementation and tooling.

[bjhargrave]

Comment author: @tjwatson

(In reply to John Ross from comment BZ#4)

Perhaps a technical solution for this could be worked in as part of section 5.4 of RFC 201 where we are requiring subsystems implementations to honor the osgi.service namespace in the Provide/Require-Capability bundle headers. If any are declared, implementations must accept them as the final service policy of the bundle (i.e. no further computation of service capabilities/requirements for the bundle is done via Blueprint, DS, or whatever).

Not sure how you are suggesting the export policy for an application is influenced by Provide/Require-Capability headers. If a service is to punch out of an application then that would be the export policy of the application, so I assume you are thinking of the Provide-Capability header. Are you thinking that is a header defined by a constituent bundle of the application? If so does that mean any Provided-Capability element in the osgi.service namespace punches through or only ones with a specific attribute/directive? Or are you suggesting the Provide-Capability header is directly defined by the application?

If we think this requirement should be solved (not sure I think it should be) then I think the meta-data to punch services through or out of the application has to be defined by the application meta-data itself.

[bjhargrave]

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

(In reply to Thomas Watson from comment BZ#5)

(In reply to John Ross from comment BZ#4)

Perhaps a technical solution for this could be worked in as part of section 5.4 of RFC 201 where we are requiring subsystems implementations to honor the osgi.service namespace in the Provide/Require-Capability bundle headers. If any are declared, implementations must accept them as the final service policy of the bundle (i.e. no further computation of service capabilities/requirements for the bundle is done via Blueprint, DS, or whatever).

Not sure how you are suggesting the export policy for an application is influenced by Provide/Require-Capability headers. If a service is to punch out of an application then that would be the export policy of the application, so I assume you are thinking of the Provide-Capability header. Are you thinking that is a header defined by a constituent bundle of the application? If so does that mean any Provided-Capability element in the osgi.service namespace punches through or only ones with a specific attribute/directive? Or are you suggesting the Provide-Capability header is directly defined by the application?

The paragraph you brought over explains what 5.4 currently does, which is separate from this issue. Regardless of what we do here, that will remain.

To clarify, comment 4 makes the proposal that services can be "punched through" an application's sharing policy by specifying a special attribute or directive on an osgi.service clause in the Provide-Capability header of a constituent bundle. The exported service would be reflected in the runtime sharing policy but not in the static sharing policy of the deployment manifest.

If we think this requirement should be solved (not sure I think it should be) then I think the meta-data to punch services through or out of the application has to be defined by the application meta-data itself.

This could be problematic since the specification makes it very clear that applications have no export policy, even to the point where application installs must be failed if there's even a whiff of exports in the manifests. At a minimum, it seems like this would need to be a new header with special "export" semantics.

I suppose another possibility would be to introduce a new subsystem type that's a hybrid of a composite and an application. We could call it osgi.subsystem.complication.

This type would allow any standard header to be declared in its manifest, like Subsystem-ExportService. But it would also retain the value of the computed application headers. It would allow folks to append additional information to computed headers using a special character, like in BND, or to disable the computation of the header by leaving the special character out.

I'm still wondering about the line between implementation and tooling, however.

[bjhargrave]

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

Per the virtual F2F, removed from RFC 201 and assigned to a future release.

[bjhargrave]

Comment author: @bjhargrave

Spec removed from Cmpn