• 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

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

Bundle Bundle Bundle Bundle Bundle
OSGi Framework
Java Runtime Environment (JRE)
Operating System (OS)
Hardware

• 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

• Different implementations of OSGI-containers:
– Equinox
• developed and used by Eclipse
– Apache Felix
• the Apache Foundation
– Knopflerfish
• developed by Makewave

Bundles
Module
Execution Environment
HW / OS
Service
Lifecycle
• 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.

• 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

org.foo.hello.cli
Client import
Import org.foo.hello
export org.foo.hello
org.foo.hello.helper
Helper org.foo.hello
Greeting

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

• 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 selfmanaged applications

• 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

• 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

• 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

org.foo.hello.cli
Client
Import org.foo.hello
import export org.foo.hello
org.foo.hello.Helper
Helper org.foo.hello
Greeting
Activator
Import org.osgi.*

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");

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

• 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

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

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

org.foo.hello
Greeting org.foo.hello
import org.foo.hello.cli
Client
Activator get
Import org.osgi.* register org.foo.hello.impl
GreetingImpl
Activator
Import org.osgi.*

• 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

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) {}

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

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

• Ch.1: OSGi revealed
• Ch 2: Mastering modularity
• Ch 3: Learning lifecycle
• Ch 4: Studying services
• Ch 11: Component models and frameworks

• 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