Charles University in PragueFaculty of Mathematics and Physics

Czech Republic

OSGi

Michal Malohlava

OSGi overview

2

CZJUG, Prague – May 28, 2008

Introduction

• Distributed Systems Research Group http://dsrg.mff.cuni.cz/ Formal methods sub-group Benchmarking gang Components team

• Components team SOFA2 component system

• http://sofa.ow2.org/

OSGi overview

3

CZJUG, Prague – May 28, 2008

Outline

• OSGi platform motivation

• OSGi architecture overview Bundles Services Example Technical background

• OSGi related projects

OSGi overview

4

CZJUG, Prague – May 28, 2008

OSGi history

• OSGi alliance Open Services Gateway initiative

• Founded 1999• OSGi specification release 1 – 2000

• OSGi specification target Define Java-based service platform, full dynamic

component model Why?

• JVM does not support natively dynamic module system - starting, stopping, updating application at runtime

• JAR dependencies management missing No way how to restrict exported packages, enforce imports

OSGi overview

5

CZJUG, Prague – May 28, 2008

OSGi motivation

• OSGi – kind of Java Operating System• Configuration of application

“LEGO” principle :-)• Reusability• Scalability• Portability

Abstraction of underlying hardware Standardized execution environment

• Application isolation/security Well defined classloading

• Easy managing life-cycle of application Dynamic updates, modification of running modules

Not-only for enterprise solutions• Embedded devices

Service oriented architecture

OSGi overview

6

CZJUG, Prague – May 28, 2008

OSGi current state

• OSGi specification Release 4.1 – May 2007

• core + compendium (contains mobile spec. from R3)

• Implementation Open source

• Eclipse Equinox Many extensions of OSGi, e.g. bundles aspects

• Apache Felix Based on Oscar (implementation of OSGi R3)

• Knopflerfish• Concierge

Implementation of OSGi R3, optimized for embedded devices

Commercial• ProSyst, Knopflerfish Pro

OSGi overview

7

CZJUG, Prague – May 28, 2008

OSGi architecture

• OSGi framework Bundles (modules) Execution environment Application life cycle Services

• Service registry

Security

• Application sharethe same JVM Isolation/security

OSGi overview

8

CZJUG, Prague – May 28, 2008

Execution environment

• OSGi platform can run on different target devices Profiles in specification

• OSGi/Minimum-1.1, CDC-1.1/Foundation-1.1

Other profiles• J2SE-1.4, J2SE-1.5

OSGi APIs only use a subset of J2SE and J2ME • Matches most profiles

• Application can enforce the profile

OSGi overview

9

CZJUG, Prague – May 28, 2008

Bundle

• Bundle Basic deployment entity (~ application, library)

Versioned (1.0.2.rc3 – major, minor, micro, qualifier)

Declaratively specified dependencies

Represented as JAR file of• Code, Resources

• Extended manifest file

• Bundle fragments Similar to bundles

• Allow extending an existing bundle represent e.g. native implementation, require a host bundle

• Bundle context Representation of bundle instance in the framework

Installation of new bundle, bundle properties

Access to persistent storage

Services management, Listeners management

Manifest-Version: 1.0Bundle-Name: LogTargetBundleBundle-Activator: LogTargetActivatorBundle-SymbolicName: LogTargetBundleBundle-Version: 1.0.0Import-Package: org.osgi.framework; version=”1.3.1”

OSGi overview

10

CZJUG, Prague – May 28, 2008

Bundle life-cycle

OSGi overview

11

CZJUG, Prague – May 28, 2008

Bundle Activator

• Class defined in MANIFEST Bundle-Activator header

• Can be an external class

• Handle bundle start/stop Start

• Register services• Create service trackers• Start threads

Stop • Release resources

Unregister services Release services

public class SimpleLogTargetActivator {

@Override public void start(BundleContext context){ /* ... */ }

@Override public void stop(BundleContext context) { /* ... */ }}

OSGi overview

12

CZJUG, Prague – May 28, 2008

Bundle dependencies

• Expose packages List all of packages + versions + attributes Fine grained package filtering

• Import bundle Require specific version(s)

• e.g. [1.0, 2.0)

• Require bundle Not recommended because it restricts further changes

in API

• Bundle class path

Export-Package: cz.*;exclude=”*Impl”

Import-Package: cz.mff.*;version=”[1.0,1.3.1)”

Require-Bundle: logger-api-bundle

Bundle-Classpath: ., lib/bsh.jar

OSGi overview

13

CZJUG, Prague – May 28, 2008

Technical background of classloading

• Separated class loaders for each bundle

• Defined lookup order Parent (only for class from java.* package)

Imported packages

Required bundles

Local class path

Image from the book OSGi in Practice, Neil Barlett

OSGi overview

14

CZJUG, Prague – May 28, 2008

Service

• Bundles – static entities Static dependencies through packages

How to communicate between bundles?

• Services – dynamics in OSGi Can appear, disappear at runtime in according to a condition

For one service name multiple providers can exist

Bundles collaboration

• Well defined communication points

Services permit bundles to detect environment and adapt their behavior

• Query language

• Service Object, registered by a bundle

• BundleContext.registerService(iface, implementation, properties)

• Service registry

• Framework automatically unregister all services of stopped bundle

Service has properties (can be modified)

Framework manages relation service <-> using bundle

OSGi overview

15

CZJUG, Prague – May 28, 2008

Registering service (1)

• Programatically in BundleActivator

• Problems Code

• Semantics is not clear dependencies, properties, implementation v. provided interface

• Simplicity

public void start(BundleContext context) { SimpleLogTargetImpl logTargetImpl = new SimpleLogTargetImpl();

registration = context.registerService(ILogTarget.class.getName(), logTargetImpl, null);

}

OSGi overview

16

CZJUG, Prague – May 28, 2008

Registering service (2)

• Declaratively Automated service management by framework

• Declarative service• Dependency injection of required services

Services provided by components• Component

Entity providing/requiring exactly specified interfaces Optional, mandatory, collection interface

<component name="logger-component"> <implementation class="cz.cuni...LoggerImpl"/> <service> <provide interface="cz...ILogger"/> </service> <reference name="TARGET" interface="cz...ILogTarget" bind="addLogTarget" unbind="removeLogTarget" cardinality="0..n" policy="dynamic"/></component>

OSGi overview

17

CZJUG, Prague – May 28, 2008

Service consuming

• Bundle can search for service which implements specific interface (defines semantics of the service)

• Several bad solution context.getService(...)

• Nasty code

Listeners• Just inform about changes

• Components Declare getter component

• Service tracker

Service reference ref = context.getServiceRef(“cz.bar”);

if (ref!=null) { Bar bar = (Bar) context.getService(ref); if (bar != null) { ... context.ungetService(ref) }}

<component name=”getServiceComp”> <implementation class=”GetLoggerService”> <reference name=”log” interface=”org.osgi...LogService” bind=”setLog” unbind=”unsetLog”</component>

OSGi overview

18

CZJUG, Prague – May 28, 2008

Service tracker

• Tracking for service Filters (name, id, property, owning bundle, ...)

• LDAP syntax (e.g. (&(objectName=”foo”)(property1=”Xyz”)) )

Adding service to registry, removing, update

//In Bundle Activator - starttracker = new ServiceTracker(context, ILogger.class.getName(), null);

tracker.open();

// get the service(s)ILogger log = (ILogger)tracker.getService();Ilogger log = (Ilogger) tracker.waitForService(1000);

// stop trackingtracker.close();

Name of service to track

ServiceTrackerCustomizer - customize behavior of adding,removing, modifying the service

OSGi overview

19

CZJUG, Prague – May 28, 2008

Whiteboard pattern

• Services dependencies Content provider v. content consumers

• e.g. Register new service if and only if the specified service appears

“Don't look for content providers, let them to register as services and track for the services”

ServiceTracker capture service life-cycle• via ServiceTrackerCustomizer

Capture process of adding/removing/modifying service

OSGi overview

20

CZJUG, Prague – May 28, 2008

Example

OSGi overview

21

CZJUG, Prague – May 28, 2008

Services

• Http Exposing registered servlets

• Event Messaging Producer <-> Consumer

• Device manager• Diagnostics/Monitoring

JMX (in Equinox sandbox)

• Application manager Application package – set of resource (bundles, data,...)

• Can be deployed/install

• Location/measurement services

OSGi overview

22

CZJUG, Prague – May 28, 2008

Security layer

• Optional

• Based on Java 2 security architecture

• 4 roles Developer

• Adds local permissions to the bundle by signing Admin, Service, Bundle permissions

Deployer• Signs the bundle and deploys it• Resulting bundle permissions = intersection of bundle and

target environment permissions

Operator• Full control all the time

End user

OSGi overview

23

CZJUG, Prague – May 28, 2008

Issues of OSGi R4

• No repository defined No single trusted point for downloading bundles

• Each implementation has its own OBR (OSGi bundle repo.)

No automatic download of required bundles/packages Currently just RFC-112

• Searching by capabilities Planned in OSGi R5

• Bundle dependency resolver Resolving bundles can take long time Maximal sharing of packages

• Stale service problem Services can exchange objects connected to a bundle classloader.

What happens when this bundle is stopped?

OSGi overview

24

CZJUG, Prague – May 28, 2008

Related projects

• rOSGi Access services in a remote OSGi

• Glassfish v3 OSGi replace HK2 (module subsystem) Uses Apache Felix

• SpringDM (Spring-OSGi) Integration of OSGi inside Spring

• Spring application platform Similar concept to OSGi, cooperates with it, reuses bundles Defines bundles repository

• JSR 277 Java Modules, proposed OSGi interoperability

OSGi overview

25

CZJUG, Prague – May 28, 2008

Q&A

Thank you!