Dynamic Modules For Java
Dynamic Modules For Java
OSGi Framework
Hardware
Review:
OSGi Layered Architecture
Service
Bundles Lifecycle
Modularity
Execution Environment
HW / OS
• Each layer depends on the layers beneath it (It is possible to use
lower OSGi layers without using upper ones, but not vice versa)
• Bundles are the unit of modularity. They further have an associated
life cycle and are the providers of services.
OSGi: The Modularity Layer
Reading
• Ch.1: OSGi revealed
• Ch 2: Mastering modularity
• Ch 3: Learning lifecycle
• Ch 4: Studying services
• Ch 11: Component models and
frameworks
Logical vs Physical Modularity
• Logical modularity refers to a form of code visibility. A
module defines a logical boundary in your application,
which impacts code visibility in a fashion similar to
access modifiers
• Physical modularity refers to how code is packaged
and/or made available for deployment. Physical
modules are sometimes also referred to as deployment
modules or deployment units.
• In general, a physical module is not necessary equal to
a logical module: it’s possible to have logical modularity
without physical modularity or to package multiple logical
modules into a single physical module
Limitations of Java Modularity
1. Low-level control of code visibility
2. Limited deployment and management support
– The classpath problem
Limitations of Java Modularity (1)
Low-level code visibility control
• What are Java modules ? Packages, jars ?
• Packages are in general too finegrained to be
considered modules
• A module would be of a size of a group of packages
(maybe in a jar – or not)
• Problem with this:
– No relationships are defined between packages
– jar files by themselves provide no visibility scoping. All the public
classes in implementation packages are visible to everyone, not
only to the other packages forming the module
Limitations of Java Modularity (2)
The classpath problem
Limitations of Java Modularity (2)
The classpath problem
• The “class path hell” arises when more than one JAR file provides
a given set of classes
• Example scenario:
– The jar file A.jar has a class pack.a.Test that needs
pack.lib.Util. During testing it was compiled against this class in
Lib.jar at version 1.2.0.
– However, during deployment the class is provided by the first jar found
on the classpath that contains pack/lib/Util.class.
– The class carries no version information, so there is no way to diagnose
problems around using that class !
– The jar file also contains no version information, so even if the class
came from Lib.jar it might be the wrong one (version 1.1.0) !
– This problem can be especially hard to diagnose when an OtherLib
only accidentally contains pack.lib.Util where its primary classes
it is meant to provide are in another package such as pack.other.
OSGi Modularity
• In OSGi, logical modularity is synonymous with
physical modularity: both the logical module
and the physical module is referred to as a
bundle
OSGi Bundles
• A Bundle is:
• “ A physical unit of
modularity in the form of
a JAR file containing
code, resources, and
metadata, where the
boundary of the JAR file
also serves as the
encapsulation boundary
for logical modularity at
execution time”.
Bundle’s role in logical modularity
• Packages (and therefore the classes in them) contained
in a bundle are private to that bundle unless explicitly
exported
• Only explicitly exported packages can be imported
(used) by other bundles
• Bundles extend standard Java access modifiers with
module private visibility (only visible in the module)
OSGi Bundle Metadata
• Metadata are contained in the Manifest file
• The OSGI manifest extends the classical jar file manifest
• The OSGI-related metadata contains the following
categories of information about the bundle:
– 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
Bundle Manifest Example
Bundle-ManifestVersion: 2
Human- Bundle-Name: Hello
readable
Bundle-Description: A Greeting Bundle
info
Bundle-Vendor: FooProducer
Bundle Bundle-SymbolicName: org.foo.hello
identificat Bundle-Version: 1.0.0.qualifier
ion Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Code Export-Package: org.foo.hello
visibility Import-Package: org.osgi.framework;version="1.5.0"
Bundle-Activator: org.foo.hello.Activator
Bundle Metadata:
(1) Human-readable information
• the OSGi framework ignores this part, it is just for
humans.
• Examples:
– Bundle-Name
– Bundle-Description
– Bundle-Vendor
– Bundle-Copyright
Bundle Metadata:
(2) Bundle Identification
• Examples:
– Bundle-SymbolicName: helps the OSGi framework to uniquely
identify a bundle
– Bundle-Version: an OSGI version-number, is taken together with
the symbolic name for bundle identification
Bundle Metadata:
(3) Code Visibility
• Internal bundle class path— bundle class path is a list of
locations to search for classes. The difference from java
class path is that the bundle class path refers to
locations inside the bundle JAR file.
– Bundle-ClassPath has a default value of . meaning that
classes are searched in the root of the bundle jar file
• Exported internal code—Explicitly exposed code from
the bundle class path for sharing with other bundles
package org.osgi.service.http;
import javax.servlet.Servlet;
public interface HttpService {
void registerServlet(Sting alias,
Servlet servlet, HttpContext ctx);
}
Example contd.
2. Follow up: two more bundles are installed:
Export-Package: org.osgi.service.http;
uses:="javax.servlet"; version="1.0.0"
Import-Package: javax.servlet; version="2.3.0"
Example contd.
4. Resolution with Uses contraints:
For the incremental case, the framework can now detect inconsistencies in the class
spaces, and resolution fails when you try to use the client bundle. Early detection is
better than errors at execution time, because it alerts you to inconsistencies in the
deployed set of bundles.
The framework can be requested to re-resolve the bundle dependencies
to remedy this situation
Example contd.
5. Consistent resolution:
Summary
• Modularity is a form of separation of concerns that provides both
logical and physical encapsulation of classes.
• Bundle is the name for a module in OSGi. It’s a JAR file containing
code, resources, and modularity metadata.
• Modularity metadata details human-readable information, bundle
identification, and code visibility.
• Bundle code visibility is composed of an internal class path,
exported packages, and imported packages.
• The OSGi framework uses the metadata about imported and
exported packages to automatically resolve bundle
dependencies and ensure type consistency before a bundle can
be used.
• Imported and exported packages capture inter-bundle package
dependencies, but uses constraints are necessary to capture intra-
bundle package dependencies to ensure complete type
consistency.