OSGI Modularity

1.What is OSGI.....??

OSGi is a specification. The core of the OSGi specification defines a component and service model for Java. The components and services can be dynamically installed, activated, de-activated, updated and de-installed.

A software component is called bundle in OSGi.

A very practical advantage of OSGi is that every bundle must define its exported Java packages and its required dependencies. This way you can effectively control the provided API and the dependencies of your plug-ins.

2.OSGI Bundles and Dependency Manegement

2.1 osgi bundles

osgi specification defines the osgi bundle as a smallest unit of a modularization. osgi bundles are technically .jar files. it contain meta information about the the bundle and explicitly define it's dependencies to other modules and services also it provide thorough information about its external API as well. this meta information basically contain in META-INF/MANIFEST.MF file.

2.2 Symbolic Name and Version

Each bundle has a symbolic name which is defined via the Bundle-SymbolicName property. The name starts by convention with the reverse domain name of the bundle author, e.g. if you own the "example.com" domain then the symbolic name would start with "com.example".

Each bundle has also a version number in the Bundle-Version property.

The Bundle-Version and the Bundle-SymbolicName uniquely identifies a bundle in OSGi.

Both properties are defined in the MANIFEST.MF file.

2.3. Semantic Versioning with OSGi

OSGi recommends to use a .. schema for the version number.
  • is increased if all changes are backwards compatible.
  • is increased if public API has changed but all changes are backwards compatible.
  • is increased if changes are not backwards compatible.

2.4. Bundle dependencies and public API

Via the MANIFEST.MF file a bundle can define its dependency to other bundles or packages. OSGi will throw a ClassNotFoundException if a class from a bundle tries to access a class without a defined dependency to it. The only exception are packages from the Java runtime environment from the standard Java virtual machine; these packages are always available. The available classes from the Java virtual machine can be configured via a JRE profile, but this configuration is not covered in this book.

In the MANIFEST.MF file a bundle also defines its API via the Export-Package Identifier. All packages which are not explicitly exported are not visible to other bundles.

All these restrictions are enforced via a specific OSGi classloader. Each bundle has its own classloader. Access to restricted classes is not possible.

A bundle can define that it depends on a certain version (or a range) of another bundle, e.g. bundle A can define that it depends on bundle C in version 2.0, while bundle B defines that it depends on version 1.0 of bundle C.

2.5 OSGi dependency management

OSGi is responsible for the dependency management between the bundles.

OSGi reads the MANIFEST.MF file of a bundle during its installation. It ensures that all dependent bundles are also resolved and activated before the bundle is activated.

If the dependencies are not met, then the bundle is not resolved.

2.6  Bundle life cycle

With the installation of a bundle in the OSGi runtime the bundle is persisted in a local bundle cache. The OSGi runtime then tries to resolve all dependencies of the bundle.

If all required dependencies are resolved, the bundle is in the RESOLVED status otherwise it is in the INSTALLED status.

If several bundles exist which would satisfy the dependency, then the bundle with the highest version is used. If the versions are the same, then the bundle with the lowest install ID will be used (the bundle gets a unique identifier assigned by the framework during the installation). If the bundle is started, its status is STARTING. Afterwards it gets the ACTIVE status.

This life cyle is depicted in the following graphic.


Post a Comment