OSGi Deep Dive: Basic Concepts (Part 1)

After writing a series of posts on the 20-day approach for the AEM Development (here), I think it is a good time to delve deep into AEM's building blocks.

One of the major technology that AEM uses is OSGi (Open Service Gateway Initiative). Therefore, in the few upcoming posts, we will be learning the OSGi concepts in detail along with code examples.

Let's get started! 🙋

Software Modularity

In modern times, a complex software can be thought of as a collection of various modules or components. These modules are normally independent of each other and modification in one module does not affect the other modules.

These modules interact with each other via an API. The API is defined as a set of classes and methods which can be used from other components.

If a module uses an API from another module, it has a dependency on the other module, i.e., it requires the other module exists and works correctly.

A module which is used by other components should try to keep its API stable. This avoids that a change affects other modules. But it should be free to change its internal implementation.

OSGi

OSGi is a Java framework for developing and deploying modular software programs and libraries.

OSGi has two parts. 

• The first part is a specification for modular components called bundles, which are commonly referred to as plug-ins. The specification defines an infrastructure for a bundle's life cycle and determines how bundles will interact.  
• The second part of OSGi is a Java Virtual Machine (JVM)-level service registry that bundles can use to publish, discover and bind to services in a service-oriented architecture (SOA).

The components and services can be dynamically installed, activated, de-activated, updated and uninstalled.

The OSGi specification has several implementations, for example, Equinox, Knopflerfish, and Apache Felix. A bundle is the smallest unit of the modularization which means in OSGi, a software component is a bundle. The bundles are also called plug-ins in the Eclipse programming model. In these posts, I am going to use bundles term but you can choose them whatever you like 😏

OSGi Metadata

OSGi bundles are nothing but .jar files with some additional metadata. This metadata is stored in /META-INF/MANIFEST.MF file. It is a standard java specification and OSGi adds additional metadata to it. Following is an example of the manifest file

Let us understand the parameters one by one

1. Bundle-Name - Short name of the bundle
2. Bundle-SymbolicName - Unique identifier for the bundle
3. Bundle-Version - Version of the bundle and it needs to be incremented if a new version of the bundle is published
4. Bundle-Activator - An optional class that implements the BundleActivator interface. When a bundle is activated, an instance of this class gets created.
5. Bundle-RequiredExectionEnvironment - Java version to run the bundle
6. Bundle-ActivationPolicy - Setting this to lazy will tell the OSGi runtime that this plug-in should only be activated if one of its components, i.e. classes and interfaces are used by other plug-ins. If not set, the OSGi runtime does not activate the plug-in, i.e., services provided by this plug-in are not available.
7. Bundle-ClassPath - Defines from where to load the classes for the bundle.

OSGi Layered Model

OSGi Layering - source: osgi architecture

• Bundles - components that are developed by the developers
• Services - this layer connects bundles in a dynamic way
• Life-Cycle - API to start, stop, update and uninstall bundles
• Modules - defines how a bundle can import or export code
• Security - handles security aspects
• Execution Environment - defines what methods and classes available in a specified platform

Bundle Lifecycle

The life cycle of a bundle can be understood according to the following illustration

Bundle lifecycle - source: vogella

To use a bundle, we do our coding and create a .jar file out of it. Then this jar is installed in the OSGi runtime (Equinox, Felix or Knopflerfish). From there, the journey begins

1. INSTALLED - The bundle is in the installed state when it is uploaded in an OSGi runtime. It will remain in this state until the runtime resolves all its dependencies.
2. RESOLVED - If all the required dependencies are resolved, the bundle comes in the RESOLVED state. But what happens if there is more than one bundle that gives the dependency? 🤔 Simple - the bundle with the higher version is used.
3. STARTING - When all the dependencies are resolved, then the OSGi runtime tries to start the bundle. During this time, the bundle is in the STARTING state
4. ACTIVE - After the successful start, the bundle becomes ACTIVE and the user can start using it.
5. STOPPING/STOPPED - We can dynamically start/stop the bundles in OSGi. When we stop the bundle from the runtime, it releases all the resources gracefully and unregisters all the services and comes in the STOPPED state.
6. UNINSTALLED - When we remove the bundle from the runtime, then it becomes UNINSTALLED. 

Conclusion

In this post, we learned about some basic concepts of OSGi and I know it is a lot of theory 😐 but it is necessary to get acquainted with the terminology we are dealing with. But worry not, from the next post onwards, we will be looking into some more OSGi concepts but with code examples 😃.

I hope you enjoyed through the post. Feel free to befriend me on Facebook, Twitter or Linked In or say Hi by email.

Happy Coding 😊 and Happy Learning 😊