OSGI is a Java platform that introduces modularity. It allows Java applications to be broken into separate bundles that can be dynamically installed and updated without restarting the JVM. Each bundle contains metadata that defines its dependencies and exported/imported packages. The OSGI framework handles loading and wiring bundles together based on their dependencies. This allows applications to be updated modularly rather than requiring redeploys of the entire application.
3. 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?
5. 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 !
8. ● 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
9. 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 ??
12. OSGI Framework
As of now, there are 3 implementations
● Apache Felix
● Eclipse Equinox
● Knopflerfish
Module Layer Lifecycle Layer
Service Layer
13. 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
14. 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
15. Bundle role in logical Modularity
● Is to logically encapsulate member classes. what does this mean ?
○ Visibility of the code
16. 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 API
Bundle-Description: Public API for a simple paint program.
Bundle-DocURL: http://www.manning.com/osgi-in-action/
Bundle-Category: example, library
Bundle-Vendor: OSGi in Action
Bundle-ContactAddress: 1234 Main Street, USA
Bundle-Copyright: OSGi in Action
17. 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
18. 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
19. 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
20.
21. 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
22. Export - Package
Export-Package : A comma-separated list of internal bundle packages to
expose 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"
23. 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 ??
25. 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 is
no such class, the search ends with an exception.
That’s it! We’ve finished the introduction to bundle metadata
30. 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.
31. 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.