OSGI Modularity

38
OSGI Modularity Pubudu Dissanayake

description

The Java platform is an unqualified success story. It’s used to develop applications for everything from small mobile devices to massive enterprise endeavours. But this success has come in spite of the fact that Java doesn’t have explicit support for building modular systems beyond ordinary object-oriented data encapsulation What does this mean to you? If Java is a success despite its lack of advanced modularization support, then you may wonder if that absence is a problem

Transcript of OSGI Modularity

Page 1: OSGI Modularity

OSGI Modularity

Pubudu Dissanayake

Page 2: OSGI Modularity
Page 3: OSGI Modularity

The What and Why of OSGI

What do you mean by “Modularity” ?

the logical decomposition of a large system into smaller collaborating pieces

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

What is OSGi?

Page 4: OSGI Modularity

Why OSGI ? Java’s modularity limitations

● Low-level code visibility control

Page 5: OSGI Modularity

Java’s modularity limitations Cont..

● Error-Prone Classpath concept

The classpath pays no attention to code versions - it returns first version it finds.

Class Path Hell !

Page 6: OSGI Modularity
Page 7: OSGI Modularity

Typical Java Application

Page 8: OSGI Modularity

● Runtime vs Compile time difference.○ Flat, single classpath.

Java’s modularity limitations Cont..

● No standard way of building a modular system.○ Class loader based techniques.

● If you need to add new functionality or update existing functionality, JVM needed to be restarted.● Can you update a part(can be a JAR file) of a running Java application?● Java lacks dynamism

Page 9: OSGI Modularity

Can OSGI help you ?

● Allow us to understand the system easily● Allow us to develop module by module● Allow us to reuse developed modules● ClassNotFoundException when starting your application● Execution time error due to wrong version of dependent library ● Packaging an application as logically independent JAR files and deploying only those pieces

you need for a given installation. ● Packaging an application as logically independent JAR files, declaring which code is accessible

from each JAR file, and having this visibility enforced.

“Yes !! ” Still not convinced ??

Page 10: OSGI Modularity

Next level of Modularity

Page 11: OSGI Modularity

An Architectural overview of OSGI

Page 12: OSGI Modularity

OSGI Framework

As of now, there are 3 implementations ● Apache Felix ● Eclipse Equinox ● Knopflerfish

Module Layer Lifecycle LayerService Layer

Page 13: OSGI Modularity

OSGI Modularity

● Is how OSGI refers to its specific realization of the module concept● Is a jar file with extra Meta-data. bundles typically aren’t entire application

packaged into single jar file.● Is more powerful than a jar file because it can explicitly declare visibility of its

packages. Thus it extends normal access modifies association with java

Bundle

Page 14: OSGI Modularity

The Bundle role in physical modularity

● Is to determine module membership ● Given class is a member of a bundle if it’s contained in the bundle jar● Bundle jar is a container of bundle metadata -- Manifest

Page 15: OSGI Modularity

Bundle role in logical Modularity

● Is to logically encapsulate member classes. what does this mean ? ○ Visibility of the code

Page 16: OSGI Modularity

Defining Bundle with metadata

● Human-readable information—Optional information intended purely as an aid to humans who are using the bundle

● Bundle identification —Required information to identify a bundle● Code visibility —Required information for defining which code is internally visible and which

internal code is externally visible

● Human-readable information

Bundle-Name: Simple Paint APIBundle-Description: Public API for a simple paint program.Bundle-DocURL: http://www.manning.com/osgi-in-action/Bundle-Category: example, libraryBundle-Vendor: OSGi in ActionBundle-ContactAddress: 1234 Main Street, USABundle-Copyright: OSGi in Action

Page 17: OSGI Modularity

Bundle identification

● For example, Bundle-Name seems like it could be a form of bundle identification

It isn’t.

unique bundle identifier was proposed to maintain backward compatibility it’s called

Bundle-SymbolicName: org.foo.shape

● only intended for the OSGi framework to help uniquely identify a bundle.

A bundle is uniquely identified by its Bundle-SymbolicName and Bundle-Version.

Bundle-SymbolicName: org.foo.shape

Bundle-Version: 2.0.0

Page 18: OSGI Modularity

OSGI Version Number format

● major – Changes for an incompatible update for both a consumer and a provider of an API.● minor – Changes for a backward compatible update for a consumer but not for a provider.● micro – A change that does not affect the API, for example, a typo in a comment● Qualifier - e.g. 1.2.0.alpha

Page 19: OSGI Modularity

Code visibility

● Internal bundle class path—The code forming the bundle● Exported internal code—Explicitly exposed code from the bundle class path for sharing with

other bundles● Imported external code—External code on which the bundle class path code depends

Recap If the JAR file has a Main-Class

java -jar app.jar

If not,java -cp app.jar org.foo.Main

Page 20: OSGI Modularity
Page 21: OSGI Modularity

Bundle-ClassPath

The Bundle-ClassPath specifies where to load classes from from the bundle.

Bundle-ClassPath: .

Loading from nested JARs (whether packed or unpacked):

Bundle-ClassPath: foo.jar,other.jar,classes

Page 22: OSGI Modularity

Export - Package

Export-Package : A comma-separated list of internal bundle packages toexpose for sharing with other bundles

Export-Package: org.foo.shape

Export-Package: org.foo.shape,org.foo.other

Export-Package: org.foo.shape; org.foo.other; version="2.0.0"

Page 23: OSGI Modularity

Import-Package

Import-Package :

A comma-separated list of packages needed by internal bundle code from other bundles.

Import-Package: org.foo.shape

there’s NO relationship among nested packages.

Import-Package: org.foo.shape,org.foo.shape.other

Import-Package: org.osgi.framework; version="1.3.0"

Version range ??

Page 24: OSGI Modularity

Version Range

Import-Package: org.osgi.framework; version="[1.3.0,2.0.0)"

“Depending on packages, not bundles.”

Page 25: OSGI Modularity

Class-search order

● If the class is from a package starting with java. ,the parent class loader is asked for the class. If the class is found, it’s used. If there is no such class, the search ends with an exception.

● If the class is from a package imported by the bundle, the framework asks the exporting bundle for the class. If the class is found, it’s used. If there is no such class, the search ends with an exception.

● The bundle class path is searched for the class. If it’s found, it’s used. If there isno such class, the search ends with an exception.

That’s it! We’ve finished the introduction to bundle metadata

Page 26: OSGI Modularity

Example ..

Page 27: OSGI Modularity

Paint Example ….

Bundle-ManifestVersion: 2Bundle-SymbolicName: org.foo.shape.circleBundle-Version: 2.0.0Bundle-Name: Circle ImplementationImport-Package: javax.swing, org.foo.shape; version="2.0.0"Export-Package: org.foo.shape.circle; version="2.0.0"

Bundle-ManifestVersion: 2Bundle-SymbolicName: org.foo.paintBundle-Version: 2.0.0Bundle-Name: Simple Paint ProgramImport-Package: javax.swing, org.foo.shape; org.foo.shape.circle;org.foo.shape.square; org.foo.shape.triangle; version="2.0.0"

Page 28: OSGI Modularity

Bundle dependency resolution - Resolving dependencies automatically

Transitive Dependencies

Page 29: OSGI Modularity

Transitive Bundle-resolution Wiring

Page 30: OSGI Modularity

Multiple Matching Package Providers

● Framework favors the highest matching version

● Sound simple enough ? What if both bundles export same version ?

● framework chooses between candidates based on the order in which they are installed in the framework.

Page 31: OSGI Modularity

Priority of Dependency

● Highest priority is given to already-resolved candidates, where multiple matches of resolved candidates are sorted according to version and then installation order.

● Next priority is given to unresolved candidates, where multiple matches of unresolved candidates are sorted according to version and the installation order.

Page 32: OSGI Modularity

Ensuring Consistency

What went wrong ?

Page 33: OSGI Modularity

Inner vs Inner bundle dependencies

Page 34: OSGI Modularity
Page 35: OSGI Modularity

Reviewing the benefits of the modular program

Page 36: OSGI Modularity

Summary

Page 38: OSGI Modularity

Thank You :)