OSGi Best Practices - Tim Ward

OSGi Best Practices

Emily Jiang

IBM

21st September 2011

Page 1 COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved, © IBM Corp. 2011
OSGi Alliance Marketing © 2008-2010 . 1
Page
All Rights Reserved

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
2

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

AGENDA

> Why OSGi?

> What is OSGi?

> How to best use OSGi?

3

© IBM Corp. 2011

Modularization in Java
Jar
> Jars have no modularization
Package
characteristics
– No “jar scoped” access modifiers. Class
Class
Class

– No means for a jar to declare its Package

dependencies. Class
Class
– No versioning. Class
Package

Class
Class
Class

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

Problems with Global Java ClassPath
Java VM party common resolver axis xerces

rt assetmaint catalina mail ezmorph xmlapis
Begin
jce hhfacility base jenks servlets xmlrpc
Here
jsse pos. datafile jakarta jetty xmlgraphics

plugin content entity log4j looks

sunjce_prov. manufact. widget httpunit jdbm

dnsns product … mx4j bsf
Class
.. bi rome batik bsh Not
marketing workflow jpos18 fop velocity Found
Exception
workeffort ecommerce jcl tomcat ws-commons

ebay oagis barcode4j poi geronimo

minerva … freemarker lucene ..

minilang googlebase serializer jdom json

accounting order naming commons xalan

guiapp ofbiz jython derby wsdl4j

© IBM Corp. 2011

webA.war

Problems with EARs/WARs
WEB-INF/classes/servletA.class
WEB-INF/lib/spring.jar
WEB-INF/lib/commons-logging.jar
WEB-INF/lib/junit.jar…
Enterprise Applications have isolated webB.war
WEB-INF/classes/servletB.class
classpaths but… WEB-INF/lib/spring.jar
WEB-INF/lib/commons-logging.jar
webC.war
WEB-INF/classes/servletC.class
> No Sharing WEB-INF/lib/spring.jar

– Common libraries/frameworks in apps WEB-INF/lib/commons-logging.jar
and memory

> Version conflicts plankton.v1

plankton.v2

© IBM Corp. 2011

AGENDA

> Why OSGi?

> What is OSGi?


7

© IBM Corp. 2011

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
Jar Package
Jar
Explicit exports
Clas
Clas Clas
Clas
Clas Clas
ss
Package ss
Package
s s
Clas
Clas Clas
Clas
Clas Clas
ss ss
s Explicit dependencies
s

© IBM Corp. 2011

OSGi Bundles and Class Loading
OSGi Bundle – A jar containing:
Classes and resources. Bundle
Class Loading
OSGi Bundle manifest.
Each bundle has its own loader.
What’s in the manifest:
No flat or monolithic classpath.
Bundle-Version: Multiple versions of
bundles can live concurrently. Class sharing and visibility decided
by declarative dependencies, not
Import-Package: What packages
by class loader hierarchies.
from other bundles does this
bundle depend upon? OSGi framework works out the
dependencies including versions.
Export-Package: What packages
from this bundle are visible and
reusable outside of the bundle?
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: MyService bundle
Bundle-SymbolicName: com.sample.myservice
Bundle-Version: 1.0.0
Bundle-Activator: com.sample.myservice.Activator
Import-Package: com.something.i.need;version="1.1.2"
Export-Package: com.myservice.api;version="1.0.0"

© IBM Corp. 2011

OSGi Bundle

Bundles have a dynamic
Bundle
lifecycle
Can come and go
independently

© IBM Corp. 2011

OSGi Service Registry
• 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

© IBM Corp. 2011

AGENDA

> Why OSGi?

> What is OSGi?


12

© IBM Corp. 2011

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 MANIFEST.MF

– Import all packages ...
Require-Bundle: com.ibm.ws.service;bundle-version=2.0.0
– Bundle version management

• Import-Package
– Can wire to any bundles exporting the specified package
– Loose coupling between bundles
– Only import the package you need MANIFEST.MF
...
– Package version management Import-Package: com.ibm.ws.service.api;version=2.0.0

© IBM Corp. 2011

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

© IBM Corp. 2011

BP2 - Split Package examples

API A Implementation C

org.hal.api 1.0.0 org.hal.a 1.0.0

API B
Bundle C
has to use 'Require-Bundle' to
org.hal.api 1.0.0 ensure that it has classes from both parts
of the API

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

© IBM Corp. 2011

BP2 - Split Package
examples

API A Implementation C

org.hal.a 1.0.0
org.hal.api 1.0.0

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

© IBM Corp. 2011

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.

© IBM Corp. 2011

BP3 - Version bundles and packages
examples
API A
org.hal.a 1.0.0
Implementation A Client A

Imports: Imports:
org.hal.a [1.0, 1.1) org.hal.a [1.0, 2.0)
API B
org.hal.a 1.0.0

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

Implementation A API A Client A

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

Implementation B API B Client B
Imports: Imports:
org.hal.a 1.1.0
org.hal.a [1.1, 1.2) org.hal.a [1.1, 2.0)

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

© IBM Corp. 2011

BP3 - Version bundles and
packages examples

Implementation A Client A

Imports: org.hal.a 1.0.0 Imports:
org.hal.a [1.0, 1.1) org.hal.a [1.0, 2.0)
API A

Implementation B API B Client B

Imports: Imports:
org.hal.a [2.0, 2.1) org.hal.a 2.0.0 org.hal.a [2.0, 3.0)

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

© IBM Corp. 2011

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

© IBM Corp. 2011

BP4 - Separate API and
implementation examples

API + Implementation Client
org.hal.myapi
org.hal.b.client
org.hal.a.impl

Both API and
implementation packages
imported by client

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

© IBM Corp. 2011

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.

© IBM Corp. 2011

BP4 & 5 - examples
API Client

org.hal.myapi org.hal.b.client

Implementation

org.hal.a.impl
API and implementation
packages in different bundles
but still imported by client

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

© IBM Corp. 2011

BP4 & 5 - examples

API Client

org.hal.myapi org.hal.b.client

Implementation

org.hal.a.impl
Client and implementation in
separate bundles, both import API. Client
uses implementation through a service
defined by the API.

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

© IBM Corp. 2011

Using services can be hard!
private BundleContext ctx; @Override
public void serviceChanged(ServiceEvent event)
private AtomicReference<LogService> ls = new {
AtomicReference<LogService>();
ServiceReference ref = event.getServiceReference();
private AtomicReference<ServiceReference> lr = new
AtomicReference<ServiceReference>();
if (ls.get() == null && event.getType() ==
ServiceEvent.REGISTERED) {
public void start(BundleContext ctx) throws
ls.set((LogService) ctx.getService(ref));
InvalidSyntaxException
{ } else if (ls.get() != null && event.getType() ==
ServiceEvent.UNREGISTERING &&
this.ctx = ctx;
ref == lr.get()) {
ctx.addServiceListener(this,
ref = ctx.getServiceReference(LogService.class.getName());
"(objectClass=org.osgi.service.log.LogService)");
if (ref != null) {
ServiceReference ref =
ctx.getServiceReference(LogService.class.getName()); ls.set((LogService) ctx.getService(ref));
if (ref != null) { lr.set(ref);
ls.set((LogService) ctx.getService(ref)); }
lr.set(ref); }
} }
}

© IBM Corp. 2011

BP6 - Use Blueprint
dependencies injected
publishes
consumes
service
service

OSGI-INF/blueprint/
A static assembly and blueprint.xml
configuration of
components (POJOs)
Blueprint bundle

• 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.)

© IBM Corp. 2011

BP6 - Blueprint service-bundle
examples
Billing service bundle

<blueprint>
<service ref=”service” interface =
”org.example.bill.BillingService” />
<bean id=”service” scope=”prototype”
class=”org.example.bill.impl.BillingServiceImpl” /> Billing
</blueprint>

-“prototype” scope indicates a
new instance is created by the
container for each use.
public interface BillingService { -“singleton” scope is the default.
void bill(Order o);
}

© IBM Corp. 2011

BP6 - Blueprint client-bundle
examples
e-Commerce bundle

<blueprint>
<bean id=”shop” class=”org.example.ecomm.ShopImpl”>
<property name=”billingService” ref=”billingService” />
</bean> e-Commerce
<reference id=”billingService”
interface=”org.example.bill.BillingService” />
</blueprint>

public class ShopImpl { -injected service reference
-service can change over time
private BillingService billingService; -can be temporarily absent
void setBillingService(BillingService srv) {
billingService = srv; without the bundle caring
} -managed by Blueprint container

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

© IBM Corp. 2011

BP7 – Make Bundles Loosely
Coupled & Highly Cohesive

FileSystemAPI
SomeotherAPI

TransactionsAPI
API Implementation

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

JPAAPI

'Hairball' effect – one
bundle has many package
dependencies

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

© IBM Corp. 2011

BP7 – Make Bundles Loosely
Coupled & Highly Cohesive
FileSystemAPI

API Implementation

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

Implementation
Implementation
Implementation
org.hal.DBlog.impl
org.hal.DBlog.impl
org.hal.DBlog.impl
DBAPI
DBAPI
DBAPI

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

© IBM Corp. 2011

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

© IBM Corp. 2011

Quiz – What best practices are used?

blog-api

Web application bundle

JNDI EM
WEB-INF/ Blogging
Blog META-INF/
web.xml Service OSGI-INF/blueprint/
persistence.xml
blueprint.xml Persistence
Service
blog-servlet OSGI-INF/blueprint/
blog blueprint.xml

blog-persistence

© IBM Corp. 2011

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

For more information on Enterprise OSGi take a look at
Enterprise OSGi in Action :
http://www.manning.com/cummins

© IBM Corp. 2011

OSGi Best Practices - Tim Ward

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (17)

Similar a OSGi Best Practices - Tim Ward

Similar a OSGi Best Practices - Tim Ward (20)

Más de mfrancis

Más de mfrancis (20)

Último

Último (20)

OSGi Best Practices - Tim Ward