If you can't read please download the document
Upload
jax-london
View
1.979
Download
2
Embed Size (px)
Citation preview
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
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
WEB-INF/lib/spring.jarWEB-INF/lib/commons-logging.jarWEB-INF/lib/junit.jar
webC.warWEB-INF/classes/servletC.class
WEB-INF/lib/spring.jarWEB-INF/lib/commons-logging.jarWEB-INF/lib/junit.jar
plankton.v1
plankton.v2
AGENDA
Why OSGi?
What is OSGi?
How to best use 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?
How to best use 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
Imports:org.hal.a [1.0, 2.0)
API B
org.hal.a 1.1.0
API A
org.hal.a 1.0.0
Client A
Imports:org.hal.a [1.0, 2.0)
Client B
Imports:org.hal.a [1.1, 2.0)
Implementation B
Imports:org.hal.a [1.1, 1.2)
Implementation A
Imports:org.hal.a [1.0, 1.1)
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
Imports:org.hal.a [1.0, 2.0)
Client B
Imports:org.hal.a [2.0, 3.0)
Implementation B
Imports:org.hal.a [2.0, 2.1)
Implementation A
Imports:org.hal.a [1.0, 1.1)
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
OSGI-INF/blueprint/blueprint.xml
OSGI-INF/blueprint/blueprint.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_RGB
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
JAX_London_2011_Autumn_Edition_RGBClick to edit Master title style
Click to edit Master text styles
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
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
JAX_London_2011_Autumn_Edition_RGBClick to edit Master title style
Click to edit Master text styles
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
Click to edit Master text styles
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
JAX_London_2011_Autumn_Edition_RGBClick to edit Master title style
JAX_London_2011_Autumn_Edition_RGB
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
Click to edit Master text styles
JAX_London_2011_Autumn_Edition_RGBClick to edit Master title style
Click icon to add picture
Click to edit Master text styles
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
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