Demistifying OSGi

42
Demystifying OSGi Sameera Jayasoma WSO2 Inc. Pradeep Fernando WSO2 Inc. Colombo Java Meetup 24-01-2013

description

The slide deck used during Colombo Java meetup.

Transcript of Demistifying OSGi

Page 1: Demistifying OSGi

Demystifying OSGi

Sameera JayasomaWSO2 Inc.

Pradeep FernandoWSO2 Inc.

Colombo Java Meetup24-01-2013

Page 2: Demistifying OSGi

Modular Systems...

Page 3: Demistifying OSGi

Image courtsy of: http://www.thefeltsource.com/Human-Anatomy.html

Page 4: Demistifying OSGi

Down the Memory Lane...

Page 5: Demistifying OSGi

Functions

Image courtsy of: http://www.slideshare.net/bjhargrave/why-osgi

Page 6: Demistifying OSGi

Modules

Image courtsy of: http://www.slideshare.net/bjhargrave/why-osgi

Page 7: Demistifying OSGi

Classes/Objects

Image courtsy of: http://www.slideshare.net/bjhargrave/why-osgi

Page 8: Demistifying OSGi

Packages

Image courtsy of: http://www.slideshare.net/bjhargrave/why-osgi

Page 9: Demistifying OSGi

Modularity with Java

Can we build a pure modular system with Java?

Page 10: Demistifying OSGi

Modularity with Java

● Yes we can... ○ Various Java libraries and Plugin systems.○ Eclipse IDE plugins○ IntelliJIDEA plugins.

● But...

Page 11: Demistifying OSGi

Modularity with Java

What are the limitations?● No standard way of building a modular system.

○ Class loader based techniques. ● Runtime Vs Compile time difference.

○ Flat, single classpath.● No model for sharing of resource at runtime.

Page 12: Demistifying OSGi

Runtime vs Compile time.

Java application. Compile time view

log4j-2.1.0.jar axis2-kernel-1.6.0.jar axiom-3.3.0.jar jdom.1.0.jar spring-core.1.0.jar

saxon-8.9.0.jar poi-3.5.0.jar wss4j-1.5.11.jar

cindy-5.7.0.jar rampart-2.3.0.jar derby-10.3.0.jar bcel-5.2.0.jar

quart-1.1.0.jar woden-1.0.0.jar

jaxb-2.2.5.jar

Page 13: Demistifying OSGi

Runtime vs Compile time

Runtime classloading architecture.

Single linear classpath.

log4j-2.1.0.jaraxis2-kernel-1.6.0.jaraxiom-3.3.0.jarjdom.1.0.jarspring-core.1.0.jarsaxon-8.9.0.jarpoi-3.5.0.jarjaxb-2.2.5.jar

wss4j-1.5.11.jarquart-1.1.0.jarwoden-1.0.0.jarcindy-5.7.0.jarrampart-2.3.0.jarderby-10.3.0.jarbcel-5.2.0.jar

Page 14: Demistifying OSGi

Multiple Library Versions

Single linear classpath.

log4j-2.1.0.jaraxis2-kernel-1.6.0.jaraxiom-3.3.0.jarjdom.1.0.jarspring-core.1.0.jarsaxon-8.9.0.jarpoi-3.5.0.jarjaxb-2.2.5.jar

wss4j-1.5.11.jarquart-1.1.0.jarwoden-1.0.0.jarcindy-5.7.0.jarrampart-2.3.0.jarderby-10.3.0.jarbcel-5.2.0.jarlog4j-3.0.0.jar

Can we achieve this in Java?

Page 15: Demistifying OSGi

Tight Coupling among modules

Image courtsy of: http://www.slideshare.net/bjhargrave/why-osgi

Page 16: Demistifying OSGi

What Next?

● How do we overcome those limitations in Java?

● We were discussing functions, module, objects and

packages.

● What next???

Page 17: Demistifying OSGi

What Next???

● How about an abstraction where you can work at the package level as opposed to class/object level?○ Importing packages.○ Exporting packages.○ A way to have private packages.

● Can we achieve the limitations that we discussed in Java from this model?

Page 18: Demistifying OSGi

Next Level of Modularity

? What next?

Image courtsy of: http://www.slideshare.net/bjhargrave/why-osgi

Page 19: Demistifying OSGi

Next Level of Modularity...

Image courtsy of: http://www.slideshare.net/bjhargrave/why-osgi

Page 20: Demistifying OSGi

Next Level of Modularity...

● Separate class loader per module. ○ creating a class-space per module.○ delegate class loading to other modules when necessary.

● Solves the single class path problem.● Now you have a class loader network formed from

classloader delegation.● This network is formed with import/export package

restrictions.● Now we have modularity at runtime as well as compile

time.

Page 21: Demistifying OSGi

Next Level of Modularity...

Java application. Runtime view

Classloader Network.

Delegate each other for

classloading requests.

Page 22: Demistifying OSGi
Page 23: Demistifying OSGi

What is OSGi?

"The OSGi framework is a module system and service platform for the Java programming language that

implements a complete and dynamic component model, something that as of 2012 does not exist in standalone

Java/VM environments."--Wikipedia

Page 24: Demistifying OSGi

What is OSGi?

● Widely accepted specification which introduces a standard way of building dynamic, modular systems with Java.

● OSGi framework implementations.(Open source)○ Eclipse Equinox.○ Apache Felix.○ Knopflerfish.

Page 25: Demistifying OSGi

OSGi Layered Model

Image courtsy of: http://www.osgi.org/Technology/WhatIsOSGi

Page 26: Demistifying OSGi

OSGi Layered Model● Bundles

○ Bundles are the OSGi components made by the developers.

● Services○ The services layer connects bundles in a dynamic way by offering a

publish-find-bind model for plain old Java objects.

● Life-Cycle○ The API to install, start, stop, update, and uninstall bundles.

Page 27: Demistifying OSGi

OSGi Layered Model● Modules

○ The layer that defines how a bundle can import and export code.

● Security ○ The layer that handles the security aspects.

● Execution Environment○ Defines what methods and classes are available in a specific platform.

Page 28: Demistifying OSGi

Bundles

● Bundle is the unit of modularization in OSGi

● OSGi based application can be considered as a collection of Bundle

● Bundles can share packages with other bundles and hide packages from otherbundles

● How does a bundle differs from a normal jar file ?

Page 29: Demistifying OSGi

Bundles...

How does a bundle differs from a normal jar file?

Page 30: Demistifying OSGi

MANIFEST.MF

Bundle-ManifestVersion : 2Bundle-Name: My First OSGi BundleBundle-SymbolicName: HelloWorldBundleBundle-Version: 1.0.0Export-Package: org.helloworldImport-package: org.osgi.framework

Private Package

Exported Package

Imported Package

Bundle

Page 31: Demistifying OSGi

Bundle States

Image courtsy of: http://static.springsource.org/s2-dmserver/2.0.x/getting-started/html/ch01.html

Page 32: Demistifying OSGi

Demo

Page 33: Demistifying OSGi

Dynamism

Modularity achieved.. but what about dynamism?

Page 34: Demistifying OSGi

Dynamism...

● The moment your instantiate a new object tight coupling among modules occurs.

● What if I want to update the platform or part of the platform during runtime.

● What we need is a ...

Page 35: Demistifying OSGi

OSGi Services

● In-VM SOA model.● OSGi Service registry.● Bundles can publish/lookup services using interface

names

Page 36: Demistifying OSGi

OSGi Services

public void start(BundleContext bc) {Hashtable props = new Hashtable();props.put("language", "en");//Registering the HelloWorld servicebc.registerService(HelloService.class.getName(),new HelloServiceImpl(), props);

}

Page 37: Demistifying OSGi

Acquiring Services

public void start(BundleContext bc) {//Get the service reference for HelloServiceserviceRef = bc.getServiceReference(HelloService.class.getName());//service reference can be null, if the service is not registered.if(serviceRef != null) {

helloService = (HelloService)bc.getService(serviceRef);} else {

System.err.println("service reference not found."); }}

Page 38: Demistifying OSGi

Listeners

● Bundle Listeners

● Service Listeners

● Service Trackers

● Declarative Services

Page 39: Demistifying OSGi

Declarative Services

<?xml version="1.0" encoding="UTF-8"?><component name="helloservice.listen"><implementation class="org.sample.HelloComponent"/><reference name="HS"

interface="org.sample.HelloService"cardinality="0..n"policy="dynamic"target="(language=en)"bind="setHelloService"unbind="setHelloService" />

</component>

Page 40: Demistifying OSGi

Demo

Page 41: Demistifying OSGi

Questions

Page 42: Demistifying OSGi

Thank you.