New specifications aplenty

OSGi release Core and Enterprise specifications for OSGi Framework 5

Chris Mayer
OSGi-Alliance-logo.1

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.

Check out all the new tidbits via
the
Release
announcement, and download
here
!

Author
Comments
comments powered by Disqus