Java Tech & Tools | OSGi Best Practices | Emily Jiang

PowerPoint Presentation

OSGi Best Practices

Emily Jiang, IBM

OSGi Developer, Apache Aries [email protected]

AGENDA

Why OSGi?

What is OSGi?

How to best use OSGi?

Jars have no modularization
characteristics

No jar scoped access modifiers.

No means for a jar to declare its dependencies.

No versioning.

Jar

Package

Class

Class

Class

Package

Class

Class

Class

Package

Class

Class

Class

Modularization in Java

Problems with Global Java ClassPath

Java 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

..

ClassNotFoundException

BeginHere

Problems with EARs/WARs

Enterprise Applications have isolated
classpaths but

No Sharing

Common libraries/frameworks in apps and memory

Version conflicts

webA.warWEB-INF/classes/servletA.class

WEB-INF/lib/spring.jarWEB-INF/lib/commons-logging.jarWEB-INF/lib/junit.jar

webB.warWEB-INF/classes/servletB.class


webC.warWEB-INF/classes/servletC.class


plankton.v1

plankton.v2

AGENDA

Why OSGi?

What is OSGi?


Jar

Jar

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

Class

Class

Class

Class

Class

Class

Package

Class

Class

Class

Class

Class

Class

Explicit exports

Explicit dependencies

OSGi Bundles and Class Loading

OSGi Bundle A jar containing:

Classes and resources.OSGi Bundle manifest.

Whats 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 Loading

Each 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

OSGi Bundle

Bundles have a dynamic lifecycle

Can come and go independently

Bundle

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

WSAD512_IntroToPortal.ppt

Page of 32

AGENDA

Why OSGi?

What is OSGi?


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

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

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

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

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.

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 B

org.hal.a 1.0.0

Client A


API B

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

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

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

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

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.

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

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

.

Using services can be hard!

@Override

public 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 ls = new AtomicReference();private AtomicReference lr = new AtomicReference();

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);

}}

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 injected

publishes
service

consumes
service

A static assembly and configuration of components (POJOs)

Blueprint bundle

OSGI-INF/blueprint/blueprint.xml

BP6 - Blueprint service-bundle examples

public interface BillingService {void bill(Order o);

}

Billing

Billing service bundle

prototype scope indicates a new instance is created by the container for each use.

singleton scope is the default.

On the provider side, the BillingServiceImpl is another POJO implementing a Java interface for which a service is registered by the Blueprint container when the Billing bundle is started.By default beans are created with singleton scope which means only a single instance is created by the container. If the bean maintains any state then it can be declared with prototype scope so that the container creates a new instance each time it needs to inject the dependency into a client.

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

e-Commerce bundle

injected service reference

service can change over time

can be temporarily absent
without the bundle caring

managed by Blueprint container

Here is a simple example of an eCommerce bundle which contains a shop bean which uses a BillingService provided by another bundle. The Blueprint container locates the Billing Service provider and injects it into the shop bean at runtime.OSGi services are dynamic so if the service provider can be changed then the blueprint container is able to dynamically rewire the reference to a new service without impacting the shop bean instance.

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

BP7 Make Bundles Loosely Coupled & Highly Cohesive

Implementation

org.hal.DBlog.impl

DBAPI

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

BP8 Use bundle repositories

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

BP8 - Use Bundle Repositories

Quiz What best practices are used?

Blogging
Service

Blog
Persistence
Service

blog-servlet

Web application bundle

META-INF/
persistence.xml

WEB-INF/web.xml



JNDI

EM

blog

blog-persistence

blog-api

What best practices used?

BP4 - Separate API from implementationsBP5 - Share services not implementationsBP6 Make bundles loosely coupled & highly cohesiveBP7 - Use Blueprint

If you show the source code, the following three best practices can be included:BP1 - Use Import-Package instead of Require-BundleBP2 - Avoid split packagesBP3 - Version bundles and packages

Questions?

Additional References

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

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

IBM Corporation 2011. All Rights Reserved.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. 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.

Copyright and Trademarks

Mastertitelformat bearbeiten

Mastertextformat bearbeiten

Zweite Ebene

Dritte Ebene

Vierte Ebene

Fnfte Ebene

JAX_London_2011_Autumn_Edition_RGB

Click to edit Master title style

Click to edit Master subtitle style


JAX_London_2011_Autumn_Edition_RGBClick to edit Master title style

Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level




Second level
Third level
Fourth level
Fifth level

Second level
Third level
Fourth level
Fifth level



Second level
Third level
Fourth level
Fifth level


Second level
Third level
Fourth level
Fifth level




Second level
Third level
Fourth level
Fifth level



Click icon to add picture




Second level

Third level

Fourth level

Fifth level



Second level

Third level

Fourth level

Fifth level

Technology

Java Tech & Tools | OSGi Best Practices | Emily Jiang