Component Models and Technologies Case Study OSGI What

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 Java Runtime Environment (JRE) Operating System (OS) Hardware Bundle

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 (METAINF/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. cli import Client Import org. foo. hello Greeting export org. foo. hello

Example: Greeting bundle Manifest files Manifest-Version: 1. 0 Bundle-Manifest. Version: 2 Bundle-Name: Hello Bundle-Symbolic. Name: org. foo. hello Bundle-Version: 1. 0. 0. qualifier Bundle-Required. Execution. Environment: Java. SE-1. 7 Export-Package: org. foo. hello Manifest-Version: 1. 0 Bundle-Manifest. Version: 2 Bundle-Name: Client Bundle-Symbolic. Name: org. foo. hello. client Bundle-Version: 1. 0. 0. qualifier Bundle-Required. Execution. Environment: Java. SE-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 selfmanaged applications

Bundle Life. Cycle • Bundle Life. Cycle 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 Bundle. Activator interface) • Upon activation a bundle gets a Bundle. Context 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 org. foo. hello. cli Client Greeting import Import org. foo. hello Activator export org. foo. hello Import org. osgi. *

Example: Greeting Bundle Activator package org. foo. hello; import org. osgi. framework. Bundle. Activator; import org. osgi. framework. Bundle. Context; public class Activator implements Bundle. Activator { public void start(Bundle. Context ctx) { System. out. println("Bundle started"); } public void stop(Bundle. Context ctx) { System. out. println("Bundle stopped"); } }

Example: Greeting bundle Manifest file with Activator Manifest-Version: 1. 0 Bundle-Manifest. Version: 2 Bundle-Name: Hello Bundle-Symbolic. Name: org. foo. hello Bundle-Version: 1. 0. 0. qualifier Bundle-Required. Execution. Environment: Java. SE-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 Client import org. foo. hello. impl Greeting. Impl Activator Import org. osgi. *

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 Greeting. Impl 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 Activator org. foo. hello. impl Greeting. Impl Import org. osgi. * register Activator Import org. osgi. *

Example: exporting Greeting Service • The Greeting. Implementation 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: Greeting. Impl Bundle Activator registers Service package org. foo. hello. impl; import org. foo. hello. Greeting; import org. osgi. framework. Bundle. Activator; import org. osgi. framework. Bundle. Context; public class Activator implements Bundle. Activator { public void start(Bundle. Context ctx) { ctx. register. Service(Greeting. class. get. Name(), new Greeting. Impl(), null); } public void stop(Bundle. Context ctx) {} }

Example: Client Bundle Client retrieves registered Service. Reference ref = ctx. get. Service. Reference(Greeting. class. get. Name()); ((Greeting) ctx. get. Service(ref)). say. Hello();

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 • Java. World: 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