Component Models and

Technologies Case Study:

OSGI
 What is OSGI ?
• Acronym comes from:
– OSGi : Open Service Gateway Initiative
– now: OSGi is a name for a Dynamic Module System
for Java
• OSGi is about building systems from
components
• OSGi is a set of specifications
– by the OSGi-Alliance (founded 1999)
– with wide adoption outside the alliance
 OSGI - History
• Initial goal of OSGI Alliance was to specify a
component model for devices
– Installable Software services
• Software deployment and management
• Security
– Originally aimed at home automation and mobile
devices
• OSGI evolved into a general component model
over Java
– Milestone: 2003: Eclipse adopts OSGI technology
OSGI – a component framework for Java

Bundle Bundle Bundle Bundle Bundle

OSGi Framework

Java Runtime Environment (JRE)

Operating System (OS)

Hardware
 OSGI concepts<-> Component Concepts

• Bundle <-> Component

– Set of classes and resources that
• have managed dependencies
• may be installed (deployed) / unnstalled at runtime
• may export services
• Service <-> Component interface
– Services are provided by bundles that register them with the container
– Services are used by bundles that request them from the container
– Some Services are standard-services provided by the container
• OSGI Container <-> Component Framework
– Runtime environment for bundles
– Life-cycle management of bundles
– Service-management
– Provider of standard services
 OSGI Containers
• Different implementations of OSGI-containers:
– Equinox
• developed and used by Eclipse
– Apache Felix
• the Apache Foundation
– Knopflerfish
• developed by Makewave
 OSGI Layered Architecture

Service
Bundles Lifecycle
Module
Execution Environment
HW / OS
• Each layer is dependent on the layers beneath it (It is possible to
use lower OSGi layers without using upper ones, but not vice versa)
• Bundles are the unit of modularity. They further have an associated
life cycle and are the providers of services.
 Module Layer
• Concern: packaging and sharing code
• The OSGI module concept = bundle
• Bundle:
– Physical presentation: a jar-file
– Contains:
• Class files, resource files, metadata in jar-manifest file (META-
INF/MANIFEST.MF)
• Manifest contains specific OSGi headers and bundle-specific
information
– Makes dependencies explicit:
• Exported and imported packages are explicitly contained in manifest
• Packages that are not explicitly exported cannot be imported by
other bundles
 Example: Greeting Bundle
Simple Module

org.foo.hello.helper

Helper

org.foo.hello
org.foo.hello.cli

Client import Greeting

Import export
org.foo.hello org.foo.hello
 Example: Greeting bundle
Manifest files
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Hello
Bundle-SymbolicName: org.foo.hello
Bundle-Version: 1.0.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Export-Package: org.foo.hello

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Client
Bundle-SymbolicName: org.foo.hello.client
Bundle-Version: 1.0.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Import-Package: org.foo.hello
 Lifecycle Layer
• Provides: execution-time module management (via API or Console)
– Bundles are not permanently on the class path, they can come and go
at any time.
– Framework supports lifecycle operations: install, update, start, stop, and
uninstall
– These lifecycle operations allow you to dynamically administer, manage,
and evolve your application at runtime
• Provides: access to the underlying OSGi framework (via API)
– bundles may gain access to their execution context (know about their
lifecycle events and other bundles)
– this provides them with a way to interact with the OSGi framework and
the facilities it provides during execution
– lets you create externally managed applications or completely self-
managed applications
 Bundle LifeCycle
• Bundle LifeCycle states:
– installed: initial state of an (installed) bundle
– resolved: all dependencies are resolved, all classes
are available, bundle is ready to be started
– starting: the bundle is in the process of starting
– active: bundle is active and running
– stopping: the bundle is in the process of being
stopped
– uninstalled: the bundle has been uninstalled, it is no
longer available for use of the framework
 OSGI Console
• Some OSGI Console commands:
– help List all available commands.
– ss List of all bundles together with their state and id.
– ss <string> List all bundles with names containing that string.
– start <id> Start up the bundle with a given id.
– stop <id> Stop the bundle with the given id.
– install <url> Install the bundle that the URL refers to.
– uninstall <id> Uninstall the bundle with the given id.
– diag <id> Show resolution problems for bundle with given id.
– exit
 API
• For each installed Bundle there is a Bundle-object that
is managed by the framework
• Each Bundle goes through a lifecycle controlled by the
framework
• Bundles may declare a given class as an activator,
which is the bundle’s hook into its own lifecycle
management (it has to implement the
BundleActivator interface)
• Upon activation a bundle gets a BundleContext
object; from this context object the bundle has access to
all the OSGi functionality for modularity, lifecycle, and
services
 Example: Greeting Bundle
with Activator

org.foo.hello.Helper

Helper

org.foo.hello
org.foo.hello.cli
Greeting
Client import
Activator

Import export Import

org.foo.hello org.foo.hello org.osgi.*
Example: Greeting Bundle
Activator

package org.foo.hello;

import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

public void start(BundleContext ctx) {

System.out.println("Bundle started");
}

public void stop(BundleContext ctx) {

System.out.println("Bundle stopped");
}
}
 Example: Greeting bundle
Manifest file with Activator
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Hello
Bundle-SymbolicName: org.foo.hello
Bundle-Version: 1.0.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Export-Package: org.foo.hello
Import-Package: org.osgi.framework;version="1.5.0"
Bundle-Activator: org.foo.hello.Activator
 Service Layer

• Additional layer of encapsulation and dynamics

• Service is:
– An object associated with a list of interfaces it
provides and properties
– Dynamic (can come and go), framed by bundle life
cycle
– By default OSGi ensures class compatibility
– Supports laziness
 Example: Greeting Bundles
Interface+Implementation Modules
org.foo.hello

Greeting

org.foo.hello

import

org.foo.hello.cli
import
Client Import
org.foo.hello.impl org.osgi.*
org.foo.hello.impl GreetingImpl

Activator
 Example: Greeting Bundles
Interface+Implementation Modules
• Goal:
– Bundles should be able to interact only through interfaces
– The Greeting is split into the Greeting interface and the
GreetingImpl implementation.
– Interface and Implementation should be contained in different
bundles, in order to allow clients to work with different
implementations.
• Problem:
– However, the client needs to import both the interface and the
implementation bundle !
• Solution:
– The client can be made independent of the implementation by
using OSGI Services.
 Example:
exporting Greeting Service
org.foo.hello

Greeting

org.foo.hello

import

org.foo.hello.cli
Client
get
Import
Activator
org.foo.hello.impl org.osgi.*

GreetingImpl
Import register Activator
org.osgi.*
 Example:
exporting Greeting Service
• The GreetingImplementation bundle instantiates a
Greeting object and registers it with the OSGI registry
(using imported org.osgi.*)
• In order to obtain an implementation of the Greeting
interface, the client bundle goes to the service registry
and looks up the interface (using imported org.osgi.*)
• Advantages of OSGi Services:
– The client bundle does not need to import the package
containing the implementation any more; the client depends only
on the interface.
– Services are dynamic: they can be registered and looked up at
any time
Example: GreetingImpl Bundle
Activator registers Service
package org.foo.hello.impl;

import org.foo.hello.Greeting;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class Activator implements BundleActivator {

public void start(BundleContext ctx) {

ctx.registerService(Greeting.class.getName(),
new GreetingImpl(), null);
}

public void stop(BundleContext ctx) {}

}
 Example: Client Bundle
Client retrieves registered Service

ServiceReference ref =
ctx.getServiceReference(Greeting.class.getName());

((Greeting) ctx.getService(ref)).sayHello();
 Limitations of OSGi Services
• Limitations:
– using raw OSGI services is intrusive into application code
(since they are built over the Service Locator Pattern)
– If Services are considered the equivalent of component
interfaces, they are not made explicit as provided and
required interfaces
– Solutions: more advanced component models are defined
over the raw OSGi:
• Examples: OSGI DS (Declarative Services), Spring Dynamic
Modules (Spring+OSGI)
Reading
• Ch.1: OSGi revealed
• Ch 2: Mastering modularity
• Ch 3: Learning lifecycle
• Ch 4: Studying services
• Ch 11: Component models and
frameworks
 How-to Tutorials
• JavaWorld: Hello OSGI Tutorial: Bundles for
beginners (detailed "how-to"tutorial for getting started
with OSGi and Equinox, building on a hello world
scenario)
• A tutorial series by Neil Bartlett:
– Part 1: Your first bundle
– Part 2: Interacting with the Framework
– Part 3: Dependencies between Bundles
– Part 4: Registering a Service
– Part 5: Consuming a Service
– Part 6: Dynamic Service Tracking
– Part 7: Introducing Declarative Services
– Part 8: Declarative Services and Dependencies