Presentation is loading. Please wait.

Presentation is loading. Please wait.

Component Models and Technologies Case Study: OSGI.

Similar presentations


Presentation on theme: "Component Models and Technologies Case Study: OSGI."— Presentation transcript:

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

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 Bundle Simple Module Import org.foo.hello export org.foo.hello org.foo.hello.helper org.foo.hello.cli Helper GreetingClient import

10 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

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 List all bundles with names containing that string. –start Start up the bundle with a given id. –stop Stop the bundle with the given id. –install Install the bundle that the URL refers to. –uninstall Uninstall the bundle with the given id. –diag 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 Bundle with Activator Import org.foo.hello export org.foo.hello org.foo.hello.Helper org.foo.hello.cli Helper Activator Client Greeting Import org.osgi.* import

16 Example: Greeting Bundle Activator 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"); }

17 Example: Greeting bundle Manifest 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 Bundles Interface+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

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

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

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

24 Example: Client Bundle Client 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 Reading Ch.1: OSGi revealed Ch 2: Mastering modularity Ch 3: Learning lifecycle Ch 4: Studying services Ch 11: Component models and frameworks

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)JavaWorld: Hello OSGI Tutorial: Bundles for beginners A tutorial series by Neil Bartlett: –Part 1: Your first bundleYour first bundle –Part 2: Interacting with the FrameworkInteracting with the Framework –Part 3: Dependencies between BundlesDependencies between Bundles –Part 4: Registering a ServiceRegistering a Service –Part 5: Consuming a ServiceConsuming a Service –Part 6: Dynamic Service TrackingDynamic Service Tracking –Part 7: Introducing Declarative ServicesIntroducing Declarative Services –Part 8: Declarative Services and DependenciesDeclarative Services and Dependencies


Download ppt "Component Models and Technologies Case Study: OSGI."

Similar presentations


Ads by Google