OSGi in Action

I am sure, “What is OSGi ?” is the main question that you have when reading this blog post. Let’s dive into deep from starting from there.

What is OSGi?

OSGi stands for Open Services Gateway initiative. It can be simply defined as a modularity layer for the Java platform.

“What is Modularity?” should be the next question that would pop up into your mind.

What is Modularity?

It is a basic rule of architecture in the design process. Modularity means designing a complete complex system from a set of logically independent pieces. These logically independent pieces are called modules.

Each module in a system defines a logical boundary. Also, a module itself is in a control of the classes which are fully encapsulated(hidden) and which are exposed to external use.

This module has 4 classes. From them, class 1,2 and 4 are internal ones (encapsulated). Class 3 is exposed to the outside (i.e public API).

Interaction of modules

The main advantages of modularity:

1. Reduce coupling(how tightly coupled or dependent)
2. Enhance cohesion(how closely aligned a module’s classes)
3. The module is small enough to understand and debug
4. Easy to monitor, control and maintain
5. Can be tested independently

Now you might think “Doesn’t Object Orientation provides this thing?”. Yes, you feel it because both are a form of separation of concerns. Even though object orientation and modularity provide similar capabilities, they actually address them at different levels of granularity.

Now you have the background knowledge about modularity to understand about OSGi framework.

OSGi Overview

The OSGi Service Platform is composed of two halves:

1. OSGi framework — The framework is the runtime that implements and
   provides OSGi functionality.
2. OSGi standard services-The standard services define reusable APIs for common tasks, such as Logging.

OSGi service platform

Let’s dig into the OSGi framework.

OSGi Framework

The OSGi specification conceptually divides the framework into three layers. In other terms, OSGi has a layered architecture. As the typical layered architecture upper layers depend on the lower layers

OSGi layered architecture

Bundle layer — This layer is concerned with packaging and sharing code.

Bundles are the OSGi components made by the developers. Simply, a bundle is a JAR file consists with extra metadata(data of data). Mainly, a bundle is a composition of code, resources and metadata.

A bundle in OSGi

These bundles are powerful than a standard JAR file because it explicitly defines which packages of the bundle are externally visible(i.e exported packages)and on which external packages a specific bundle is depended(i.e imported packages). All of these details are included in the manifest.mf file.

Writing the manifest.mf file is a most important task when building an OSGi bundle. However, writing that file correctly is not an easy task. Therefore, you need to use a tool to generate it. Maven bundle plugin an example to use for it.

Here is a MANIFEST.mf file sample.

Manifest-Version: 1.0
Bnd-LastModified: 1533278848639
Build-Jdk: 1.8.0_171
Built-By: anuradha
Bundle-ManifestVersion: 2
Bundle-Name: org.wso2.carbon.student.mgt
Bundle-SymbolicName: org.wso2.carbon.student.mgt
Bundle-Version: 4.4.11
Created-By: Apache Maven Bundle Plugin
Export-Package: org.wso2.carbon.student.mgt;uses:="org.wso2.carbon.student.mgt.data";version="4.4.11",org.wso2.carbon.student.mgt.data;version="4.4.11"
Import-Package: org.wso2.carbon.student.mgt.data
Main-Class: 
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.6))"
Tool: Bnd-3.5.0.201709291849

Lifecycle layer — This layer is concerned with providing run-time module management and access to the underlying OSGi framework.

This layer serves in two ways: external to your application and internal to your application.

External: How bundles go through their life cycle(depicts in the below image) and how those stages allow you to manage and evolve the application dynamically.

Internal: How bundles gain access to their execution context, which provides them with a way to interact with the OSGi framework and the facilities it provides during execution.

OSGi bundle’s life cycle

BundleContext.installBundle() operation creates a bundle in the INSTALLED state. That is the entrance to the life cycle. There is no direct path from INSTALLED to STARTING. The reason is the framework ensures all
dependencies of a bundle are satisfied before it can be used.

INSTALLED to RESOLVED state transition happens only if all dependencies are satisfied. Thus, a bundle can go to the STARTING state only it guaranteed that all dependencies are satisfied.

The transition from the STARTING to the ACTIVE state is always implicit. When a bundle’s activator’s start method executes while the bundle is in STARTING state and start() method completed successfully, it jumps to the ACTIVE state. On the other hand, if an exception is thrown from the activator’s start() method, the bundle goes back to RESOLVED state via STOPPING state.

Why is that bundle stay at RESOLVED state without going to INSTALLED state??

Because its dependencies are still satisfied and no need to be resolved again.

However, there is a chance to force the framework to resolve a bundle again by refreshing it or updating it. Thus, the transition from RESOLVED to INSTALLED happens due to refreshing or updating.

A bundle in the INSTALLED state can be uninstalled, which will transition it to the UNINSTALLED state. If you uninstall an active bundle, the framework will automatically stop the bundle first, which results in the appropriate state transitions to the RESOLVED state and then transition it to the INSTALLED state before uninstalling it.

Cool. Now you know the complete bundle life cycle.😀

Service layer — This layer is concerned with interaction and communication among modules, specifically the components contained in them.

The bundle interaction happens through services. Service providers publish their services into a service registry and service clients search the
registry to find available services to use.

Cool 😎 Now you are saturated from basics of OSGi. Wait for the next post to experience these theories.