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

OSGi Framework

Bundle Bundle Bundle Bundle

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

• 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.

Service

Lifecycle

Module

Execution Environment

HW / OS

Bundles

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 BundleSimple Module

Import org.foo.hello

export org.foo.hello

org.foo.hello

org.foo.hello.helper

org.foo.hello.cli

Helper

GreetingClient import

Example: Greeting bundleManifest files

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: HelloBundle-SymbolicName: org.foo.helloBundle-Version: 1.0.0.qualifierBundle-RequiredExecutionEnvironment: JavaSE-1.7Export-Package: org.foo.hello

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: ClientBundle-SymbolicName: org.foo.hello.clientBundle-Version: 1.0.0.qualifierBundle-RequiredExecutionEnvironment: JavaSE-1.7Import-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 Bundlewith Activator

Import org.foo.hello

export org.foo.hello

org.foo.hello

org.foo.hello.Helper

org.foo.hello.cli

Helper

ActivatorClient

Greeting

Import org.osgi.*

import

Example: Greeting BundleActivator

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 bundleManifest file with Activator

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: HelloBundle-SymbolicName: org.foo.helloBundle-Version: 1.0.0.qualifierBundle-RequiredExecutionEnvironment: JavaSE-1.7Export-Package: org.foo.helloImport-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 BundlesInterface+Implementation Modules

org.foo.hello.cli

Client Import org.osgi.*org.foo.hello.impl

GreetingImpl

Activator

org.foo.hello

Greeting

import

org.foo.hello.impl

org.foo.hello

import

Example: Greeting BundlesInterface+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.cliClient

Import org.osgi.*org.foo.hello.impl

GreetingImpl

Activator

org.foo.hello

Greeting

import

register

get

org.foo.hello

Import org.osgi.*

Activator

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 BundleActivator 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 BundleClient 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