[news.eclipse.technology.equinox] Re: OSGi? --- Overview

["Olivier Gruber" <ogruber@xxxxxxxxxx>]

Here is an overview of OSGi. It has no pretention to be complete, on the
contrary, it is focused on the core platform concepts and functionality.
Above the core platform, OSGi defines many services such as an HTTP service,
a servlet engine, a logging service, or more administrative services such as
configuration. I am not presenting those, for information, please go to
www.osgi.org and download the specification. The intent here is to provide a
concise description (I know, not so concise :-) that will help moving
forward our analysis of Equinox and understand where OSGi could prove very
usefull.

The Open Services Gateway Initiative is a standard body, which started as
defining a service gateway for broadband connection. The gateway, a Java
platform, sits in between a local network of devices and remote service
providers. The gateway, in a home or a car for e.g., is intended to run
added-value services by controlling local devices. For instance, one may
envision the ability to remotely control the heating system of a weekend
house or providing real-time driving directions in a car leveraging a GPS.
Indeed, the Hertz Never-Lost system would be a perfect example of a service
that an OSGi platform in a car could provide. Phone services such as
call-waiting, caller-ids, or conference calling are other examples if the
phone is perceived as a human-interface device sitting in front of a home
gateway at the end of a broadband connection.

OSGi is one of the most advanced specification I am aware of that turns a
Java Runtime Environment (J2SE or J2ME) into a shared Java platform for
network-deployed software components. OSGi specifies a framework, above a
JRE, that manages software components in the Java Virtual Machine (JVM)
through class loaders. The OSGi framework also provides a service-oriented
architecture, leveraging software components. OSGi is small... we are
talking 66 Java class files for the abstract implementation of the
specification, 89 Java class files for a concrete implementation of the
specification.

This 155 class files for quite a powerful framework for managing Java
software components. It is important to insist that OSGi focuses on the
intra-JVM life-cycle management of components. It does not specify how
software components shall be managed persistently on the local platform
(file system, flash memory, or others).  To add a local management layer
under OSGi framework that is Eclipse compatible, we need to add about
another 50 class files. So in about 200 class files, we would be replacing
most of the org.eclipse.core.boot and org.eclipse.core.runtime plug-ins,
which constitutes the Eclipse platform layer. Only remains the plug-in
registry classes, which are specific to Eclipse model. The entire class
loading scheme would be delegated to OSGi.

Another important point, often misunderstood, is that OSGi does not specify
how components are downloaded. Again, OSGi specifies the life cycle in the
JVM of downloaded components, it does not specifies how these components are
downloaded. The framework includes a full local administration API for
allowing a local bundle to download and install other components. The usage
of this API is secured through special permissions. Actually, OSGi specifies
a secure platform through Java2 security.

Enough of what OSGi is not, and let's see what OSGi is. :-)

OSGi advocates a simple software component model, called bundles, as a
straight extension to Java. An OSGi bundle is the unit of deployment, a jar
file packaging Java class files and resources (bitmaps, icons, or data
files). A bundle may also contain native code as shared libraries such as
DLLs, which are described in the bundle manifest. OSGi does not specify how
bundles are downloaded onto the platform, but it defines the runtime
life-cycle management of bundles once they are downloaded. Bundles can be
installed or updated dynamically, while the framework is running and with
minimal disruption to already loaded components and running services.

The framework loads bundles in isolation, cleverly using Java class loaders.
Although bundles are by default isolated, bundles may export or import
packages as declared in their manifest. When exporting a package, a bundle
exports both the Java types and resources present in that package. The
corollary is that a bundle may import packages exported by other bundles.
Exported packages constitute a global name space for Java types and
resources, shared across all loaded bundles. If conflict should arise, i.e.
two bundles are exporting two versions of a same package, the OSGi platform
ensures that only the newest version of a package is visible in the global
name space. Regarding class and resource loading, the global name space
always over-rides the bundle-local name spaces.

A bundle defines an activator class, whose purpose is to install the bundle.
In other words, when the framework loads a bundle, it creates an instance of
the activator class, called the activator object. The framework first tries
to resolve the bundle, that is, satisfy its imports. In a resolved state, a
bundle is already making its exports available. A resolved bundle may be
activated, in which case the framework calls the start method on the bundle
activator object. That start method is supposed to carry the necessary
bundle-specific installation steps. In particular, it creates and registers
the services the bundle wants to export and may lookup for some services
provided by others. When the bundle needs to be unloaded, the framework
first revokes the services registered by that bundle, and then stops the
bundle by calling the stop method on the activator object.

OSGi also promotes a service framework that is built above bundles. A
service in OSGi is a Java object that implements one or more Java
interfaces, and/or extends a super class. OSGi advocates a strong separation
between the interfaces and the implementation. Services are registered in a
registry, provided by the OSGi platform. The registry provides an LDAP-like
naming space for services where a service can be associated with properties¾
name/value pairs. The registry provides a simple query language for looking
up services. One can query for registered services based on either their
supported interfaces or their properties.

A service lookup returns a service reference from which the service object
can be obtained. Using a service requires listening to service events, sent
by the platofrm. These events notify listeners about started and stopped
services. A service user must listen to service events to know when the
service references he uses become invalid. One may also use the service
events to know when a service becomes finally available, rather than
actively polling the registry until it does.

Service events are complemented in OSGi with bundle events, notifying
listeners about bundle life cycle events (loaded, resolved, started, and
stopped). These event frameworks and other specific interfaces provide a
complete local administration API. With adequate administration rights, a
normal bundle can therefore fully control the local platform, in particular
what bundles are installed and which ones are active.

Two very important points to stress out about OSGi. Firstly, OSGi does not
mandate any particular administration policies, it simply offers the needed
local mechanisms. Secondly, OSGi does not mandate any over-the-wire download
mechanism either¾ protocol or policy. OSGi does not specify when, how, and
from where bundles should be downloaded. The OSGi specification starts once
a bundle has been downloaded onto the local machine and is ready to be
loaded, resolved, and potentially activated.

These two points are often not stressed out enough and many believe that
OSGi is an end-to-end specification for network deployment of software
components. It is not. OSGi defines what a software component is and how it
is packaged. OSGi also defines a service-oriented architecture. But OSGi
does not define any web infrastructure to publish bundles to and to deploy
them from.

Best regards,

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center