Component Models and Technologies Case Study: OSGI

1. Component Models and Technologies Case Study:OSGI

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

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

4. OSGI – a component framework for Java Bundle Bundle Bundle Bundle Bundle OSGi Framework Java Runtime Environment (JRE) Operating System (OS) Hardware

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

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

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

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

9. Example: Greeting BundleSimple Module org.foo.hello.helper Helper org.foo.hello org.foo.hello.cli import Client Greeting export org.foo.hello Import org.foo.hello

10. Example: Greeting bundleManifest 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

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

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

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

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

15. Example: Greeting Bundlewith Activator org.foo.hello.Helper Helper org.foo.hello org.foo.hello.cli Greeting import Client Activator Import org.osgi.* export org.foo.hello Import org.foo.hello

16. Example: Greeting BundleActivator package org.foo.hello; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; publicclass Activator implements BundleActivator { publicvoid start(BundleContext ctx) { System.out.println("Bundle started"); } publicvoid stop(BundleContext ctx) { System.out.println("Bundle stopped"); } }

17. Example: Greeting bundleManifest 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

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

19. Example: Greeting BundlesInterface+Implementation Modules org.foo.hello Greeting org.foo.hello import org.foo.hello.cli import Import org.osgi.* Client org.foo.hello.impl org.foo.hello.impl GreetingImpl Activator

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

21. Example: exporting Greeting Service org.foo.hello Greeting org.foo.hello import org.foo.hello.cli Client get Import org.osgi.* org.foo.hello.impl Activator GreetingImpl Import org.osgi.* Activator register

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

23. Example: GreetingImpl BundleActivator registers Service packageorg.foo.hello.impl; import org.foo.hello.Greeting; import org.osgi.framework.BundleActivator; import org.osgi.framework.BundleContext; publicclass Activator implements BundleActivator { publicvoid start(BundleContext ctx) { ctx.registerService(Greeting.class.getName(), newGreetingImpl(), null); } publicvoid stop(BundleContext ctx) {} }

24. Example: Client BundleClient retrieves registered Service ServiceReference ref = ctx.getServiceReference(Greeting.class.getName()); ((Greeting) ctx.getService(ref)).sayHello();

25. 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)

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

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