OSGi in a Nutshell

In this post, I will explain simply about what is modularity , what is OSGi OSGi and what are the basic concepts in OSGi.

What is modularity ?

We can define modularity in simple term:

When writing and implementing a program or a system, rather implementing it as a single monolithic design, we can implement it as different independent unique modules. Then a standardized interface should be used to enable the communication among the modules. This will help developers to helps us minimize coupling, optimize application development, and reduce system complexity.

Modularity enables programmers to do functionality testing in isolation and engage in parallel development efforts during a given sprint or project. This increases efficiency throughout the entire software development life-cycle.

Java provides some aspects of modularity in the form of object orientation, but it was never intended to support coarse-grained modular programming.

What is OSGi?

OSGi (Open Service Gateway Initiative) is a Java framework for developing and deploying modular software programs and libraries. The OSGi(Open Services Gateway initiative) framework provides a dynamic modular architecture which has been used in many applications such as Eclipse Equinox, Apache Felix, etc

Let’s see some basic concepts in OSGi:

Bundle

OSGi bundle is nothing but JAR of java classes containing manifest.mf file which defines names of the classes which are exported, imported, version of bundle, bundle name etc.

• Bundle defines the module concept. Bundles are the development unit of OSGi. Typical OSGi application consists with multiple bundles. Bundles can share packages and hide packages in a consistent manner.
• On the deployment stage, each bundle is a jar. But the basic difference between a bundle jar and normal jar is, bundle jar consists OSGi specific manifest definition and some OSGi specific classes.
• Through manifest.mf metadata file, Module layer declare which contained packages in JAR file are visible to outside, and declare on which external packages the bundle depend.

A sample MANIFEST file can be seen below. Let’s look at the meaning of each part in definition.

• Bundle-SymbolicName: As the only mandatory definition in the MANIFEST file, symbolic name defines the unique name of the bundle in OSGi ecosystem. As this definition should be unique, it is generally defined as the base package name of the bundle by convention.
• Bundle-Description: The description about the “raison d’être” of the bundle.
• Bundle-ManifestVersion: The manifest version of the bundle.
• Bundle-Version: OSGi bundle version. major.minor.patch version
• Bundle-Activator: This class is used to control the bundle’s life cycle. This class is called by the OSGi to start or stop the bundle.
• Export-Package: Packages that is wanted to be used by other bundles are defined in this section. This provides the list of java packages that this bundle exposes
• Import-Package: This provides the Packages that is needed for the execution of current bundle.

The image below shows the concept of modularity in OSGi framework. So the application is loosely coupled and can be isolated into different independent components easily.

Modularity in OSGi framework

Service

To provide the interaction between bundles, services are used. Services are specified by Java interface. Bundles can implement this interface and register the service with the Service Registry. Clients of the service can find it in the registry.

OSGi services can be published/looked up using two ways.

1. Bundle Activator.

Bundle a provides a service of printing “Hello world”. So to expose the service to other bundles, the service should be registered.

Creating a service

Service Host- Bundle A- implements the service

Here we register the service using Bundle Activator.

Service host Bundle A- registers and exports the service

When another bundle B wants to consume the service, bundle activator of that bundle should consume that service.

Service consumer Bundle B- discovers and consumes that service

2. Declarative service

This is an alternative approach to OSGi services API’s. This is annotation based implementation. This reduces the complexity of OSGi. Declarative service data are stored in OSGI-INF/serviceComponents.xml

Life Cycle

OSGi life cycle

OSGi structure provides the necessary mechanisms to control the life cycle of the bundles.

• INSTALLED- This state indicates that the installation step has been successfully completed. In this case, neither dependency analysis nor the class loading is made. Only required steps are performed, such as defining bundle properties analysing its Manifest file.
• RESOLVED- Bundle is found in this state when OSGi resolves and satisfies all of its dependencies and makes class loading operations. This is the state that comes before starting and after stopping.
• STARTING- This is the state that bundle is found when the “start” method of the Activator of the bundle is called, but not yet as successfully or unsuccessfully finished.
• ACTIVE- The bundle is successfully started and running meaning the “start” method of the Activator resulted success.
• STOPPING- This is the state that bundle is found when the “stop” method of the Activator of the bundle is called, but not yet as successfully or unsuccessfully finished.
• UNINSTALLED- This is the state when the bundle is removed from the system. In this situation, there is no transition to another state. The component must be installed again.

Now you have got some basic understanding in OSGi.

OSGi in simple diagram!

OSGi in simple!

Reference:

• OSGi in Action: Creating Modular Applications in Java- Book by David Savage, Karl Pauls, Richard S. Hall, and Stuart McCulloch

Tutorial: Building your first OSGi Remote Service

OSGi - Simple Hello World with services