OSGi release Core and Enterprise specifications for OSGi Framework 5
The OSGi Alliance reveals new specifications within the fifth release of their namesake framework – including new repository and resolver services
The OSGi Alliance have published the latest specifications for the release of OSGi Framework R5 – a big release which will both standardise the OSGi Bundle Repository (OBR) and introduce a new Resource API for modeling generic capabilities and requirements.
The dual specification announcement, for both OSGi Core and Enterprise 5 sees a raft of advances, but not too much on from the already-available Early Access Draft. Most of what is significant in the official release however is in the Enterprise version, bringing in some important specifications.
First up of the newcomers is the Repository specification, an API that provides declarative access to artifact repositories, based on the generic capabilities and requirements model. This is important as it can theoretically hook up to remote repositories. The Reference Implementation of the Repository is currently being worked on in the JBoss OSGi project. David Bosschaert, a member of the OSGi Enterprise Expert Group (EEG), provides more on what this can enable:
With this API you can do things like: ‘I need a bundle that exports package javax.servlet version 2.5’ or you can say ‘I need a bundle that provides a Declarative Services implementation version 1.2’ without having to know what the name of the bundle is. The Repository can be used with any kind of resource (it doesn’t have to be an OSGi bundle) and it works with any type of capability. So you can also make your own capabilities and express requirements in terms of those to find your resources.
Next is the Resolver Service Specification, designed to work as a bridge with the Repository Service, whenever possible. OSGi has had resolvers for a long time but has lacked a simple embedder to get it all running seamlessly. Now, the new specification allows other entities to use this resolver as a standalone entity as well. Bosschaert adds further:
The Resolver can obviously be used to resolve OSGi type of requirements, which can be used to evaluate what-if scenarios. The Resolver is stateless, and doesn’t need to perform its operations in relation to the local framework, so it can be used to see whether a bundle or set of bundles would resolve in another framework. Additionally, the Resolver can be used on any type of constraint that can be expressed as generic capabilities and requirements, and, as with the Repository, it doesn’t need to operate on bundles per se.
Other new specifications of note include Subsystems Service that groups multiple bundles into one entity and provides isolation features to allow multiple subsystems to run under the same framework (implemented in Apache Aries) and Service Loader Mediator, which addresses common problems with bundles that rely on the java.util.ServiceLoader API.
For the Core R5 release, two new capabilities are available – a new Resource API and the debuting Version Range class, giving access to version ranges. All in all, it’s a promising step forward from the OSGi Alliance to introduce a sense of standardisation to the whole thing. With last month’s welcoming of the Residential (the first of its kind) and Compendium 4.3 releases, things are looking good for the OSGi Alliance, and for those that use the specifications. We can expect certified OSGi R5 implementations imminently from Eclipse Equinox 3.8 and Apache Felix 4.0 too.