OSGI Modularity
-
Upload
pubudu-lasal-dissanayake -
Category
Software
-
view
314 -
download
0
description
Transcript of OSGI Modularity
OSGI Modularity
Pubudu Dissanayake
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?
Why OSGI ? Java’s modularity limitations
● Low-level code visibility control
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 !
Typical Java Application
● 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
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 ??
Next level of Modularity
An Architectural overview of OSGI
OSGI Framework
As of now, there are 3 implementations ● Apache Felix ● Eclipse Equinox ● Knopflerfish
Module Layer Lifecycle LayerService Layer
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
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
Bundle role in logical Modularity
● Is to logically encapsulate member classes. what does this mean ? ○ Visibility of the code
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
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
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
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
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
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"
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 ??
Version Range
Import-Package: org.osgi.framework; version="[1.3.0,2.0.0)"
“Depending on packages, not bundles.”
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
Example ..
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"
Bundle dependency resolution - Resolving dependencies automatically
Transitive Dependencies
Transitive Bundle-resolution Wiring
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.
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.
Ensuring Consistency
What went wrong ?
Inner vs Inner bundle dependencies
Reviewing the benefits of the modular program
Summary
References
● http://moi.vonos.net/java/osgi-classloaders/
● http://blog.osgi.org/2011/05/what-you-should-know-about-class.html
● OSGi in Action: Creating Modular Applications in Java by: Richard Hall, Karl Pauls, Stuart McCulloch, David Savage (01 May 2011)
Thank You :)