Skip to main content

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 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. 


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 FacebookTwitter or Linked In or say Hi by email.

Happy Coding 😊 and Happy Learning 😊


Post a Comment

Popular posts from this blog

Day 00: AEM Developer Series

Hello everyone! Welcome to this AEM development series. We can all see the revolution of Digital Marketing today. Companies are dying to be a part of it and they have made this a war for the Digital Marketing tools.
Adobe is way ahead in this war and has gained a lot of market capture. They are leaders in the Digital Marketing platforms since 2014-15. One of the flagship product in Adobe's Digital Marketing suite is Adobe Experience Manager (AEM).
Since AEM is in huge demand, the people who know how to develop on AEM are also in huge demand. But developing on AEM is not easy as it is made up of various open-source technologies such as Apache Felix (OSGi), Apache Sling, Apache Oak and Adobe's own technologies like Granite, HTL etc. Learning all these technologies in conjunction can sometimes become confusing and frustrating 😫.
When I first started learning AEM in 2016, I was dumbfounded to see there is so much going on under the hood. I then spent months to gather all the res…

Day 05: Working with Sling Servlets in AEM

Day 03: Setting up AEM Development Environment