osgi sun 20080820

OSGi Service Platform:Java Modularity and Beyond

Richard S. Hall

Sun MicrosystemsSanta Clara

August 20th, 2008

Agenda

OSGi Service Platform OverviewOSGi as a Java Modularity Layer

Majority of the presentation

OSGi as a Service-Oriented Application FrameworkApache Felix AdvertisementConclusion

OSGi Service Platform Overview

OSGi Alliance

Formerly the Open Services Gateway InitiativeIndustry consortiumDefines OSGi Service Platform specification

Two partsFramework specification for hosting dynamically downloadable servicesStandard service specifications

Several expert groups define the specificationsCore Platform Expert Group (CPEG) – frameworkMobile Expert Group (MEG) – mobile telephonyVehicle Expert Group (VEG) – automobileEnterprise Expert Group (EEG) – enterprise issuesResidential Expert Group (REG) – gateway devices

OSGi Architectural Overview

Hardware

Driver Driver Driver

Operating System

Java

OSGi

Fram

ework

Bundle

OSGi Framework

Module-oriented frameworkBundles (i.e., modules)Package sharing and version management

Separate class loader per bundleClass loader graph, independent namespaces

Life-cycle management and notification

Service-oriented development modelSingle JVM instancePublish/find/bind intra-VM service model

Open remote management architectureNo prescribed policy or protocol

Explicit support for run-time dynamismJava Permissions used to secure framework

OSGi Framework Layering

CDCCDC

ExecutionEnvironment

L0 - •OSGi Minimum Execution Environment•CDC/Foundation•JavaSE


CDCCDC



MODULEL1 - Creates the concept of modules (aka. bundles) that use classes from each other in a controlled way according to system and bundle constraints


CDCCDC




LIFECYCLEL2 - Manages the life cycle of bundle in a bundle repository without requiring the VM be restarted


CDCCDC




LIFECYCLEL2 - Manages the life cycle of bundle in a bundle repository without requiring the VM be restarted

SERVICE MODEL L3 – Provides a publish/find/bind service model to decouple bundles

OSGi Momentum

OSGi technology has moved beyond original target domainInitial success story was Eclipse RCPMore recent success stories in enterprise scenarios

IBMSpring Dynamic ModulesBEAOracleJBossJOnASGlassFish

OSGi as a Java Modularity Layer

Standard Java Modularity Limitations (1/2)

Limited scoping mechanismsNo module access modifier

Simplistic version handlingClass path is first version found

Implicit dependenciesDependencies are implicit in class path ordering

Split packages by defaultClass path approach searches until if finds, which can lead to shadowing or mixing of versions


Limited scoping mechanismsNo module access modifier

Simplistic version handlingClass path is first version found

Implicit dependenciesDependencies are implicit in class path ordering

Split packages by defaultClass path approach searches until if finds, which can lead to shadowing or mixing of versions

JAR files do have some mechanisms in these areas, but they are insufficient


Low-level support for dynamicsClass loaders are complicated to use

Unsophisticated consistency modelCuts across previous issues, it is difficult to ensure class space consistency

Missing module conceptClasses are too fine grained, packages are too simplistic, class loaders are too low levelJAR file is best candidates, but still inadequateModularity is a second-class concept


Low-level support for dynamicsClass loaders are complicated to use

Unsophisticated consistency modelCuts across previous issues, it is difficult to ensure class space consistency

Missing module conceptClasses are too fine grained, packages are too simplistic, class loaders are too low levelJAR file is best candidates, but still inadequateModularity is a second-class concept

To be fair, Java never intended to provide a module layer, yet...

OSGi Framework Modularity Support

However, OSGi resolves these modularity-related deficiencies now (and for a few years)

OSGi bundle defines an explicit boundary for a moduleBundle metadata explicitly declares versioned dependencies on other codeFramework automatically manages bundle code dependenciesFramework enforces sophisticated consistency rules for class loading within and among bundlesFramework supports dynamic module life-cycle management

Bundle

Again, a bundle is a module in OSGi terminologyWhat is a bundle?

Bundle


Simply a JAR file plus module metadataModule metadata is stored in META-INF/MANIFEST.MF

Defines what the module provides and requires

What does a bundle JAR contain?

Bundle




What does a bundle JAR contain?Java classes (i.e., standard JAR file content)Resources (e.g., configuration files, images, etc.)Native codeEmbedded JAR files

Bundles have their own class path

Bundle




What does a bundle JAR contain?Java classes (i.e., standard JAR file content)Resources (e.g., configuration files, images, etc.)Native codeEmbedded JAR files

Bundles have their own class path

If a bundle JAR file doesn't use advanced features, then it can be both a standard JAR file and a bundle at the same time

Bundle Life Cycle

INSTALLED

RESOLVEDUNINSTALLED

STARTING STOPPING

ACTIVE

explicit

automatic

install

updateuninstall resolve

uninstall

start

stop

Bundle Life Cycle

UNINSTALLED

STARTING STOPPING

ACTIVE

explicit

automatic

updateuninstall

uninstall

start

stop

INSTALLED

install

resolve

RESOLVED

Resolving a bundle, resolves

its code dependencies

Bundle Dependency Resolution

The framework automatically resolves dependencies before a bundle is used

Matches bundle’s requirements to providers of those requirements

Package imports/exportsExplicit bundle dependenciesBundle fragment dependencies

Ensures consistency of requirements with respect to versions and other constraints

If a bundle cannot be successfully resolved, then it cannot be used

Dependency Resolution Illustration

A bundle is a module contained in a JAR file

OSGi framework

Provided package

existingbundle



OSGi framework

installbundle.jar

existingbundle



OSGi framework

resolvebundle

existingbundle



OSGi framework

automatic packagedependency resolution existing

bundle

Package Dependencies

Be aware, bundles express dependencies in terms of packages (typically)

This is a somewhat novel approach

Why?




Why?Mimics import package model already known to developers




Why?Mimics import package model already known to developersSpecifies what instead of who

More flexibleCan be resolved from different providersProviders can be refactored




Why?Mimics import package model already known to developersSpecifies what instead of who

More flexibleCan be resolved from different providersProviders can be refactored

Amenable to metadata generation

OSGi Modularity Functionality (1/7)

Multi-version support (i.e., side-by-side versions)Possible to have more than one version of a shared package in memory at the same timeAllows multiple applications to run in the same VM or sub-components of a single application to depend on different versions of the same librariesHas impacts on the service-oriented aspects of the OSGi framework

For a given bundle, the service registry is implicitly partitioned according to the package versions visible to it


Explicit code boundaries and dependenciesBundles explicitly expose internal packages (i.e., export)

Exporters export precise package versions

Bundles explicitly declare dependencies on external packages (i.e., import)

Importers may specify an open or closed version range






Export-Package: bar; version="1.0.0"Import-Package: foo; version="[1.0.0,1.5.0)"






Support for various sharing policies, e.g,Implementation package with limited backwards compatibilitySpecification packages with defined backwards compatibility

Export-Package: bar; version="1.0.0"Import-Package: foo; version="[1.0.0,1.5.0)"


Arbitrary export/import attributes for more controlExporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributes

Exporters may declare attributes as mandatoryMandatory attributes provide simple means to limit package visibility

Importers influence package selection using arbitrary attribute matching


Arbitrary export/import attributes for more control Exporters may attach arbitrary attributes to their exports, importers can match against these arbitrary attributes



Export-Package: foo; version="1.0.0"; myattr="myvalue"

Export-Package: foo; version="1.0.0"

Afoo(myattr=“myvalue”) Bfoo





Afoo(myattr=“myvalue”) BfooCfoo

Import-Package: foo; version="1.0.0"; myattr="myvalue"





Afoo(myattr=“myvalue”)

Import-Package: foo; version="1.0.0"; myattr="myvalue"

Cfoo Bfoo


Sophisticated class space consistency modelIn addition to dependency resolutionExporters may declare package “uses” dependencies

Exported packages express dependencies on imported or other exported packages, which constrain the resolve process

The framework must ensure that importers do not violate constraints implied by “uses” dependencies





DfooA foo

Export-Package: foo Export-Package: foo





DfooA foo C foobar

Import-Package: foo, bar





DfooA foo B barfoo

Import-Package: fooExport-Package: bar; uses:="foo"

C foobar





DfooA foo C foobarB barfoo

Import-Package: fooExport-Package: bar; uses:="foo"


Package filtering for fine-grained class visibilityExporters may declare that certain classes are included/excluded from the exported package



foofriend=“yes”(include:=”*”)

foo(exclude:=”*Impl”)

A

Export-Package: foo; exclude:="*Impl", foo; friend="yes"; mandatory:="friend"



foo(exclude:=“*Impl”)

A CfooB foo

Import-Package: foo; friend="yes"

Import-Package: foo




A

Import-Package: foo

CfooB foo



Import-Package: foo; friend="yes"



A

Import-Package: foo

CfooB foo



Import-Package: foo; friend=“yes”


Bundle fragmentsAllows bundle content to be extendedA special bundle that attaches to a host bundle and uses the same class loader

Conceptually becomes part of the host bundle, allowing a logical bundle to be delivered in multiple physical bundles




fooAbaz barBwoz

Fragment-Host: BExport-Package: fooImport-Package: baz

Bundle-SymbolicName: BExport-Package: barImport-Package: woz




fooAbaz barBwoz




barBwozfooAbaz




bar

foo

BfooAbaz

woz

baz


Bundle dependenciesAllows for tight coupling of bundles when requiredImport everything that another, specific bundle exportsAllows re-exporting and split packages



B barfoo

bar

A

Require-Bundle: AExport-Package: bar

Bundle-SymbolicName: AExport-Package: bar, foo



foo

bar

A

Require-Bundle: AExport-Package: bar

Bundle-SymbolicName: AExport-Package: bar, foo

B bar

OSGi Run-time Class Search Order

found?

delegate toexporter’s class loader

belongs to animported package?

no

no

found?

delegate to exporters’class loaders

found?

search localclass path

nofound?

lookupfailed

lookupsucceeded

no

no

yes

yes

yes

yes

load classor find resource

yes

delegate to parent class loader

belongs to a packageexported by a

required bundle?

yes

nobelongs to a java.*package?

no

yes

OSGi Bundle Manifest Example

Bundle-ManifestVersion: 2Bundle-SymbolicName: org.foo.simplebundleBundle-Version: 1.0.0Bundle-Activator: org.foo.ActivatorBundle-ClassPath: .,org/foo/embedded.jarBundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86Import-Package: osgi.service.log; version="[1.0.0,1.1.0)"; resolution:="optional"Export-Package: org.foo.service; version=1.1; vendor="org.foo:"; exclude:="*Impl", org.foo.service.bar; version=1.1; uses:="org.foo.service"


Bundle-ManifestVersion: 2Bundle-SymbolicName: org.foo.simplebundleBundle-Version: 1.0.0Bundle-Activator: org.foo.ActivatorBundle-ClassPath: .,org/foo/embedded.jarBundle-NativeCode: libfoo.so; osname=Linux; processor=x86, foo.dll; osname=Windows 98; processor=x86Import-Package: osgi.service.log; version="[1.0.0,1.1.0)"; resolution:="optional"Export-Package: org.foo.service; version=1.1; vendor="org.foo"; exclude:="*Impl", org.foo.service.bar; version=1.1; uses:="org.foo.service"

Indicates R4semantics and syntax



Indicates R4semantics and syntaxGlobally unique ID



Life cycle entry point



Internal bundle class path



Native code dependencies



Optional dependency on apackage version range



Provided package witharbitrary attribute and

excluded classes



Provided package withdependency on exported

package

OSGi Modularity Best Practices

Partition public and non-public classes into separate packages

Packages with public classes can be exportedNon-public classes are not exported

Use package imports rather than bundle dependencies

Allows substitutability of package providers

Limit fragment useAvoid use of dynamic imports

Special type of optional import that is resolved at run time, instead of resolve timeIntended for Class.forName() or SPI-like use cases

OSGi Modularity Tool Support

Leveraging OSGi modularityText editor + jar

Just add metadata to your JAR file's manifest

EclipsePlug-in Development Environment directly supports bundles

Bundle packaging toolsBND from Peter KriensApache Felix Maven Bundle Plugin based on BND

OSGi as a Service-Oriented Application

Framework

Service Orientation

The OSGi framework promotes a service-oriented interaction pattern among bundles

Publish Find

Interact

ServiceRegistry

ServiceProvider

ServiceRequester

ServiceDescription

OSGi Applications

A collection of bundles that interact via service interfaces

Bundles may be independently developed and deployedBundles and their associated services may appear or disappear at any time

Resulting application follows a Service-Oriented Component Model approach

Combines ideas from both component and service orientation

Bundle Life Cycle (Revisited)

INSTALLED

RESOLVEDUNINSTALLED

STARTING STOPPING

ACTIVE

explicit

automatic

install

updateuninstall resolve

uninstall

start

stop

Bundle Life Cycle (Revisited)

UNINSTALLED

explicit

automatic

updateuninstall

uninstall

INSTALLED

install

resolve

STARTING STOPPING

ACTIVE

start

stop

RESOLVED

Activating a bundle allows itto provide and use services

Bundle Activation

Bundles can hook into their life cycle by implementing a bundle activator

Notifies them when they are started/stoppedGives them access to their bundle context

Which is how they access framework capabilities, e.g.,Bundle life cycle managementPublishing or looking up services

Bundle Activation

Bundles can hook into their life cycle by implementing a bundle activator

Notifies them when they are started/stoppedGives them access to their bundle context

Which is how they access framework capabilities. e.g.,Bundle life cycle managementPublishing or looking up services

Just a simple Java interface

public interface BundleActivator{ public void start(BundleContext context) throws Exception; public void stop(BundleContext context) throws Exception;}

Service Provision Illustration

Conceptually, a bundle contains a single component which is the bundle activator

OSGi framework

Provided service

Provided package

existingbundle

component



OSGi framework

installbundle.jar

existingbundle

component



OSGi framework

activatebundle

existingbundle

component



OSGi framework

automatic packagedependency resolution existing

bundlecomponent



OSGi framework

manual servicedependency resolution

existingbundle

component

Service-Oriented Applications

Moving beyond the bundle activator as a component...Bundles can be seen as deployment units for component types

These component types can be automatically instantiated, resolved, and managed dynamically at run time

Service-Oriented Applications

Moving beyond the bundle activator as a component...Bundles can be seen as deployment units for component types

These component types can be automatically instantiated, resolved, and managed dynamically at run time

This view adopts a more general service-oriented component model approach

Not directly supported by OSGi, but is enabled by itGoal is to enable a more POJO-based approach to creating OSGi applications

i.e., the application code does not directly depend on OSGi API

Service-Oriented Application Illustration

OSGi framework

installbundle.jar

existingbundle

component

Bundles contained component types to be instantiated and managed


activatebundle

OSGi framework

existingbundle

component



OSGi framework

automatic packagedependency resolution

existingbundle

component



OSGi framework

instantiatecomponents

existingbundle

component



OSGi framework

automatic servicedependency resolutionand maintenance with

DS, Spring-DM, oriPOJO

existingbundle

component


Service-Oriented Application Advantages

Lightweight servicesDirect method invocation

Structured codePromotes separation of interface from implementationEnables reuse, substitutability, loose coupling, and late binding

DynamicsLoose coupling and late binding make it possible to support run-time management of modules

Application's architectural configuration is defined by the set of deployed bundles

Just deploy the bundles that you need

Service-Oriented Application Issues

ComplicatedRequires a different way of thinking

Things you need might not be there or go away at any moment

Must manually resolve service dependenciesMust track and manage service dynamics

There is helpService Tracker

Still somewhat of a manual approachOld-fashioned approach

Declarative Services (DS), Spring-OSGi, iPOJOSophisticated service-oriented component frameworksAutomated dependency injectionMore modern, POJO-oriented approaches

Declarative Services Example (1/2)

package foo.impl;public class HelloImpl implements foo.HelloService { LogService log; protected void setLog(LogService l) { log = l; } protected void unsetLog(LogService l) { log = null; } public void sayHello(String s) { log.log(LogService.LOG_INFO, "Hello " + s); }}

Declarative Services provides a minimally intrusive way to

Define components that provide and use servicesAutomate dependency resolution and maintenance

Declarative Services Example (2/2)

<?xml version="1.0" encoding="UTF-8"?><component name="example.hello"> <implementation class="foo.impl.HelloImpl"/> <service> <provide interface="foo.HelloService"/> </service> <reference name="LOG" interface="org.osgi.service.log.LogService" bind="setLog" unbind="unsetLog" /></component>

Declarative Services component metadata

iPOJO Example (1/2)

iPOJO provides an extensible POJO-based way toAn Apache Felix sub-projectDefines components that provide and use servicesAutomates dependency resolution and maintenanceDefines composite components with sub-service visibility scopingUses byte-code manipulation to simplify OSGi programming model

iPOJO Example (2/2)

package foo.impl;

@Component@Providespublic class HelloImpl implements foo.HelloService { @Requires LogService log; public void sayHello(String s) { log.log(LogService.LOG_INFO, "Hello " + s); }}

iPOJO simplifies metadata via byte-code reflection

OSGi Application Development Approach

Modules vs. “Modules + Services”It is possible to use only the modularity aspects of the OSGi framework and not use services as a way of structuring your applicationMay be necessary if another component model is already in use or application interaction is structured differently

OSGi Application Development Approach

Modules vs. “Modules + Services”It is possible to use only the modularity aspects of the OSGi framework and not use services as a way of structuring your applicationMay be necessary if another component model is already in use or application interaction is structured differently

Bundled vs. HostedAn application can be a set of collaborating bundles that can be deployed on any framework orAn application can host an embedded instance of the framework to create an extensibility/plugin mechanism

Often ties the application to a specific framework implementation

Apache Felix Advertisement

Apache Felix (1/3)

Top-level Apache projectApache licensed OSGi implementation

FrameworkVersion 1.0.4 currently availableCompletely stable and functional, but not all specification features implemented yet

New 1.2.0 version expected soon

ServicesPackage Admin, Start Level, URL Handlers, Declarative Services, UPnP Device, HTTP Service, Configuration Admin, Preferences, User Admin, Wire Admin, Event Admin, Meta Type, and LogOSGi Bundle Repository (OBR), Dependency Manager, Service Binder, Shell (TUI and GUI), iPOJO, Mangen

Apache Felix (2/3)

Strong communitySeveral regular committers and many regular contributors

Very responsive community

Code granted and contributed from several organizations and communities

Grenoble University, ObjectWeb, CNR-ISTI, Ascert, Luminis, Apache Directory, INSA, DIT UPM, Day Management AG, JaywaySeveral community member contributions

Apache Felix (3/3)

Apache Maven Bundle PluginMerges OSGi bundle manifest with Maven2 POM fileAutomatically generates metadata, such as Bundle-ClassPath, Import-Package, and Export-Package

Greatly simplifies bundle development by eliminating error-prone manual header creation process

Automatically creates final bundle JAR fileAlso supports embed required packages, instead of importing them

Conclusions

Conclusions

Java needs improved modularity supportLagging behind .NET in this area for yearsThe OSGi framework provides it now

And has a proven track record for many years

Importance and relevance of OSGi is growingIndustry support for mobile applicationsSignificant uptake in the enterprise space

Work underway on R4.2 specification that will show the fruit of Java EE focus

Questions?

osgi sun 20080820

Technology

osgi terminology

presentation osgi

osgi alliance

osgi momentum osgi technology

osgi framework layeringl3

osgi framework layeringl2

osgi framework layeringl1

years osgi bundle