Professional Documents
Culture Documents
Component Models and Technologies Case Study: Osgi
Component Models and Technologies Case Study: Osgi
OSGi Framework
Hardware
OSGI concepts<-> Component Concepts
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
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
package org.foo.hello;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;
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;
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