osgi best practices - tim ward

COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved, © IBM Corp. 2011

OSGi Best Practices

Emily Jiang

IBM

21st September 2011

OSGi Alliance Marketing © 2008-2010 . All Rights Reserved

Page 1

21.09.11

2

Legal

> IBM and WebSphere are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide.

> Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

> OSGi and the OSGi logo are trademarks or registered trademarks of the OSGi Alliance

> Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml

OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved,© IBM Corp. 2011

http://www.ibm.com/legal/copytrade.shtml

21.09.11

3

AGENDA

> Why OSGi?

> What is OSGi?

> How to best use OSGi?


OSGi Alliance © 2008-2011 . All Rights Reserved,© IBM Corp. 2011

21.09.11

44

> Jars have no modularization characteristics– No “jar scoped” access modifiers.– No means for a jar to declare its

dependencies.– No versioning.

JarJar

PackagePackage

ClassClassClassClass

ClassClass

PackagePackage


ClassClassPackagePackage


ClassClass

Modularization in Java

21.09.11

Problems with Global Java ClassPathJava VM

log4j

barcode4j

axis

batik

commons

derby

fop

ezmorph

freemarker

httpunit

jakarta

jcl

json

jdbm

jdom

jenks

jpos18

jython

looks

lucene

mail

mx4j

naming

jetty

poi

resolver

rome

serializer

servlets

tomcat

velocity

ws-commons

xalan

wsdl4j

xerces

xmlgraphics

xmlrpc

xmlapis

..

geronimo

bsh

bsf

guiapp

hhfacility

manufact.

marketing

minerva

accounting

assetmaint

base

bi

catalina

common

oagis

order

ebay

content

datafile

ecommerce

entity

googlebase

ofbiz

widget

minilang

party

pos.

product

workeffort

workflow

…

sunjce_prov.

plugin

jsse

jce

rt

dnsns

..

…ClassNot

FoundException

BeginBeginHereHere



21.09.11

Problems with EARs/WARs

Enterprise Applications have isolated classpaths but…

> No Sharing– Common libraries/frameworks in apps

and memory

> Version conflicts

webA.war

WEB-INF/classes/servletA.class

WEB-INF/lib/spring.jar

WEB-INF/lib/commons-logging.jar

WEB-INF/lib/junit.jar…webB.war

WEB-INF/classes/servletB.class



WEB-INF/lib/junit.jar…webC.war

WEB-INF/classes/servletC.class



WEB-INF/lib/junit.jar…

plankton.v1

plankton.v2

21.09.11

7

AGENDA

> Why OSGi?

> What is OSGi?



21.09.11

JarJar

88

What is OSGi?“The dynamic module system for Java”> Mature 10-year old technology> Governed by OSGi Alliance: http://www.osgi.org> Used inside just about all Java-based middleware

– IBM WebSphere, Oracle WebLogic, Red Hat JBoss, Sun GlassFish, Paremus Service Fabric, Eclipse Platform, Apache Geronimo, (non-exhaustive list)http://www.osgi.org/wiki/uploads/News/2008_09_16_worldwide_market.pdf

Package

ClasClasssClasClasssClasClasss

Package

ClasClasssClasClasssClasClasssPackage


Package


Explicit exports

Explicit dependencies


http://www.osgi.org/

http://www.osgi.org/wiki/uploads/News/2008_09_16_worldwide_market.pdf


21.09.11

OSGi Bundles and Class LoadingOSGi Bundle – A jar containing:

Classes and resources.OSGi Bundle manifest.

What’s in the manifest:Bundle-Version: Multiple versions of

bundles can live concurrently.Import-Package: What packages

from other bundles does this bundle depend upon?

Export-Package: What packages from this bundle are visible and reusable outside of the bundle?

Class LoadingEach bundle has its own loader.No flat or monolithic classpath.Class sharing and visibility decided

by declarative dependencies, not by class loader hierarchies.

OSGi framework works out the dependencies including versions.

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: MyService bundleBundle-SymbolicName: com.sample.myserviceBundle-Version: 1.0.0Bundle-Activator: com.sample.myservice.ActivatorImport-Package: com.something.i.need;version="1.1.2"Export-Package: com.myservice.api;version="1.0.0"

Bundle

21.09.11

OSGi Bundle

Bundles have a dynamic lifecycle

Can come and go independently

Bundle


21.09.11

• Service• An object associated with a list of classes (usually interfaces) it

provides• Dynamic (can come and go), framed by bundle lifecycle• Services are the primary means of collaboration between bundles.

S

OSGi Service Registry


21.09.11

12

AGENDA

> Why OSGi?

> What is OSGi?




21.09.11

BP1 - Use Import-Package not Require-Bundle

Require-Bundle – Tightly coupled with a particular bundle with the specified symbolic name and

version– High coupling between bundles– Import all packages – Bundle version management

• Import-Package – Can wire to any bundles exporting the specified package– Loose coupling between bundles– Only import the package you need– Package version management

MANIFEST.MF

...

Require-Bundle: com.ibm.ws.service;bundle-version=2.0.0

MANIFEST.MF

...

Import-Package: com.ibm.ws.service.api;version=2.0.0


21.09.11

BP2 - Avoid split packages

• Split package– A package is exported by two bundles at the same version and the set of

classes provided by each bundle differs.

• Why?– Leads to the use of Require-Bundle, compromising the extent to which systems

using the bundles can be extended and maintained.

• How?– Keep all of the classes from any one package in a single bundle


21.09.11

BP2 - Split Package examples

API A

org.hal.api 1.0.0

API B

org.hal.api 1.0.0

Implementation C

org.hal.a 1.0.0

Bundle C has to use 'Require-Bundle' to

ensure that it has classes from both parts of the API

Figure 1. Consumers of split packages need to use the Require-Bundle header


21.09.11

BP2 - Split Package examples

API A

org.hal.api 1.0.0

Implementation C

org.hal.a 1.0.0

Figure 2. A complete package exported from a single bundle maintains high bundle cohesion


21.09.11

BP3 - Version bundles and packages• What is semantic versioning?

– Uses a major.minor.micro.qualifier numbering scheme• Major - Packages with versions that have different major parts are

not compatible both for providers as well as consumers.• Minor – API enhancement, e.g. adding methods to an API• Micro – bug fixing• Qualifier – identifier such as timestamp• Example: 1.1.2.20101122am, 1.0.0, 2.0

– Changes in major: a binary incompatible, minor: enhanced API, micro: no API changes

• Why?– Clients can protect themselves against API changes that might break

them.


21.09.11

BP3 - Version bundles and packages examples

Figure 3: A client and an implementation can use either of two equivalently versioned packages

Implementation A

Imports:org.hal.a [1.0, 1.1)

API A

org.hal.a 1.0.0

API Borg.hal.a 1.0.0

Client A


API Borg.hal.a 1.1.0

API A

org.hal.a 1.0.0

Client A


Client B


Implementation B


Implementation A


Figure 4: How a client and implementation are affected differently by a minor API version change


21.09.11

BP3 - Version bundles and packages examples

Figure 5. How clients and implementations are similarly affected by a major API version change

org.hal.a 1.0.0

org.hal.a 2.0.0

API B

Client A


Client B


Implementation B


Implementation A


API A


21.09.11

BP4 - Separate API from Implementations

• Why?– Great flexibility– Many implementation bundles → enable more services provided– Reduce package dependencies → reduce circular dependencies

• How?– Put API classes in one bundle– Put implementation classes in a separate bundle


21.09.11

BP4 - Separate API and implementation examples

Figure 6. Badly designed provider bundle where the API and implementation classes are in the same bundle

API + Implementation

org.hal.myapi

org.hal.a.impl

Client

org.hal.b.client

Both API and implementation packages

imported by client


21.09.11

BP5 - Share services not implementations

• Use the OSGi service registry to construct instances• Why?

– Able to obtain an instance of an implementation without knowing which one– Achieve a loosely coupling of client, API and implementation

• How?

– Register an instance of the API interface in the OSGi service registry– Register an implementation of the OSGi ServiceFactory interface in the OSGi

service registry.


21.09.11

BP4 & 5 - examples

API

org.hal.myapi

Client

org.hal.b.client

API and implementation packages in different bundles

but still imported by client

Implementation

org.hal.a.impl

Figure 7. Badly designed provider bundles where the API and implementation classes have been separated


21.09.11

BP4 & 5 - examples

API

org.hal.myapi

Client

org.hal.b.client

Client and implementation in separate bundles, both import API. Client uses implementation through a service

defined by the API.

Implementation

org.hal.a.impl

Figure 8: Well designed provider bundles where the API and implementation classes have been separated


21.09.11

Using services can be hard!@Overridepublic void serviceChanged(ServiceEvent event) {ServiceReference ref = event.getServiceReference();

if (ls.get() == null && event.getType() == ServiceEvent.REGISTERED) {

ls.set((LogService) ctx.getService(ref));} else if (ls.get() != null && event.getType() ==

ServiceEvent.UNREGISTERING &&ref == lr.get()) {ref = ctx.getServiceReference(LogService.class.getName());if (ref != null) {ls.set((LogService) ctx.getService(ref));lr.set(ref);}}}

private BundleContext ctx;

private AtomicReference<LogService> ls = new AtomicReference<LogService>();private AtomicReference<ServiceReference> lr = new AtomicReference<ServiceReference>();

public void start(BundleContext ctx) throws InvalidSyntaxException{this.ctx = ctx;ctx.addServiceListener(this, "(objectClass=org.osgi.service.log.LogService)");ServiceReference ref = ctx.getServiceReference(LogService.class.getName());if (ref != null) {ls.set((LogService) ctx.getService(ref));lr.set(ref);}}


21.09.11

BP6 - Use Blueprint

• Specifies a Dependency Injection container, standardizing established Spring conventions

• Configuration and dependencies declared in XML “module blueprint”, which is a standardization of Spring “application context” XML.

– Extended for OSGi: publishes and consumes components as OSGi services• Simplifies unit test outside either Java EE or OSGi r/t.• The Blueprint DI container can be a part of the server runtime

(compared to the Spring container which is part of the application.)

dependencies injectedpublishesservice consumes

service

A static assembly and configuration of

components (POJOs)Blueprint bundle

OSGI-INF/blueprint/blueprint.xml


21.09.11

BP6 - Blueprint service-bundle examples

public interface BillingService {void bill(Order o);

}

Billing

<blueprint> <service ref=”service” interface =

”org.example.bill.BillingService” /> <bean id=”service” scope=”prototype”

class=”org.example.bill.impl.BillingServiceImpl” /></blueprint>

Billing service bundle

-“prototype” scope indicates a new instance is created by the container for each use.-“singleton” scope is the default.


21.09.11

BP6 - Blueprint client-bundle examples

public class ShopImpl {private BillingService billingService;void setBillingService(BillingService srv) {

billingService = srv;}

void process(Order o) {billingService.bill(o);}

}

e-Commerce

<blueprint> <bean id=”shop” class=”org.example.ecomm.ShopImpl”> <property name=”billingService” ref=”billingService” /> </bean> <reference id=”billingService”

interface=”org.example.bill.BillingService” /></blueprint>

e-Commerce bundle

-injected service reference-service can change over time-can be temporarily absent without the bundle caring-managed by Blueprint container


21.09.11

BP7 – Make Bundles Loosely Coupled & Highly Cohesive

'Hairball' effect – one bundle has many package

dependencies

org.hal.log.impl

Implementation

org.hal.log.impl

SomeotherAPI

DBAPI

TransactionsAPI

FileSystemAPI

JPAAPI

API

org.hal.log.api org.hal.fslog.impl

Figure 9. Poorly purposed system where a single bundle provides multiple implementations of the same API


21.09.11

BP7 – Make Bundles Loosely Coupled & Highly Cohesive

Implementation

org.hal.DBlog.implDBAPI

API

org.hal.log.api

Implementation

org.hal.fslog.impl

FileSystemAPI

Implementation

org.hal.DBlog.impl

DBAPI

Implementation

org.hal.DBlog.impl

DBAPI

Figure 10. A well purposed system where each implementation of an API is provided by a separate bundle


21.09.11

Summary – OSGi Best Practices

> BP1 - Use Import-Package instead of Require-Bundle> BP2 - Avoid split packages> BP3 - Version bundles and packages> BP4 - Separate API from implementations> BP5 - Share services not implementations> BP6 - Use Blueprint > BP7 - Make bundles loosely coupled & highly cohesive

21.09.11

Quiz – What best practices are used?

BloggingService Blog

PersistenceService

blog-servlet

Web application bundle

META-INF/persistence.xml

WEB-INF/

web.xml OSGI-INF/blueprint/blueprint.xml

OSGI-INF/blueprint/blueprint.xml

JNDI EM

blog

blog-persistence

blog-api



21.09.11

Questions?

21.09.11

Additional References

OSGi Best Practiceswww.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html

Enterprise OSGi YouTube Channel: www.youtube.com/user/EnterpriseOSGi

For more information on Enterprise OSGi take a look at Enterprise OSGi in Action :

http://www.manning.com/cummins


http://www.ibm.com/developerworks/websphere/techjournal/1007_charters/1007_charters.html

http://www.youtube.com/user/EnterpriseOSGi

http://www.manning.com/cummins

osgi best practices - tim ward

Technology

osgi bundles

osgi logo

osgi framework

osgi bundlebundles

osgi alliance marketing

osgi alliance community

best use osgi

trademarks of ibm