Have you ever wondered “What OSGi is?”. OSGi stands for Open Service Gateway Initiative, which is a Java framework for developing and deploying modular software programs and libraries. So basically, OSGi acts as the “modularity layer” of the Java application.
Wait… but What is “Modularity”?
Modularity is a software designing architecture, this modularity concept came with Java 9 and addressed two fundamental needs of all large Java applications,
- Reliable configuration
- Strong encapsulation
So basically modularity enables the program to separate the functionality of a large program into independent, interchangeable modules, in such a way that each contains everything necessary to execute only one aspect of the desired functionality. So each module in the system has its own boundary and in a single module, it controls the classes which are fully encapsulated from other modules which expose only the functionalities.
By bringing the application of the module system to the Java SE 9 platform it:
- Enabled the platform implementations to be customized for scenarios ranging from small computing devices to dense cloud deployments
- Improved security by encapsulating implementation-internal APIs
- Improved performance through more effective ahead-of-time, whole-program optimization techniques.
- Improved coding, testing, and debugging due to a small number of classes in individual modules rather than the whole large code.
OSGi into Play
The OSGi Service Platform provides a mechanism for developing applications by using a component model and deploying those applications into an OSGi framework. The OSGi architecture is separated into several layers that provide benefits to creating and managing Java applications.
As you can see in figure 1.1 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.
- Bundle Layer
- Life-cycle Layer
- Services Layer
1.0 Bundle Layer
This layer is concerned with packaging and sharing code. so what is the OSGi bundle?
OSGi bundle is nothing but JAR of java classes, resource files containing a manifest.mf file which defines names of the classes which are exported, imported, version of the bundle, bundle name etc.
The OSGi bundle defines the module concept, which again brings the “Modularity”. Bundles are the development unit of OSGi. Typical OSGi application consists of multiple bundles. Bundles can share packages and consistently hide packages. In the deployment stage, each bundle is a jar. But the basic difference between a bundled jar and a normal jar is, bundle jar consists of OSGi specific manifest definition and some OSGi specific classes. Via Manifest.mf metadata file, Module layer declare which contained packages in the JAR file is visible to outside, and declare on which external packages the bundle depend.
So writing the Manifest.mf file is the 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 is an example to use for it. Below you can find what Manifest.mf file looks like.
Manifest-Version: 1.0
Bnd-LastModified: 1618862826488
Build-Jdk: 1.8.0_281
Built-By: Maneesha
Bundle-Description: Simple User Registration Module with REST API.
Bundle-DocURL: http://www.wso2.org/
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-ManifestVersion: 2
Bundle-Name: org.wso2.carbon.identity.user.registration.smu.core
Bundle-SymbolicName: org.wso2.carbon.identity.user.registration.smu.co
re
Bundle-Vendor: WSO2
Bundle-Version: 0.0.1
Created-By: Apache Maven Bundle Plugin
DynamicImport-Package: *
Export-Package: org.wso2.carbon.identity.user.registration.smu.core;Class=org.wso2.carbon.user.core.service.RealmService)";effective:=act
ive,osgi.service;filter:="(objectClass=org.wso2.carbon.utils.Configur
ationContextService)";effective:=active,osgi.ee;filter:="(&(osgi.ee=J
avaSE)(version=1.8))"
Service-Component: OSGI-INF/org.wso2.carbon.identity.framework.user.re
gistration.smu.core.component.xml
Tool: Bnd-3.2.0.201605172007
2.0 Life-Cycle Layer
This layer is concerned with providing run-time module management and access to the underlying OSGi framework.
A Life-Cycle layer adds bundles that can be dynamically installed, started, stopped, updated and uninstalled. Bundles rely on the module layer for class loading but add an API to manage the modules in run time. The life cycle layer introduces dynamics that are normally not part of an application. Extensive dependency mechanisms are used to assure the correct operation of the environment. Life cycle operations are fully protected with the security architecture.
- INSTALLED —
BundleContex.installBundle(), the operation creates a bundle in this state. - RESOLVED — All Java classes that the bundle needs are available. This state indicates that the bundle is either ready to be started or has stopped.
- STARTING — The bundle is being started, the
BundleActivator.start()the method has been called but the start method has not yet returned. When the bundle has an activation policy, the bundle will remain in the STARTING state until the bundle is activated according to its activation policy. - ACTIVE — The bundle has been successfully activated and is running; its Bundle Activator start method has been called and returned. If there is an error in the ACTIVE state it will go to the RESOLVED state again, this jumps to RESOLVED state because in that state all the dependencies are resolved so no need to jump to the INSTALLED state again.
- STOPPING — The bundle is being stopped. The BundleActivator.stop() method has been called but the stop method has not yet returned.
- UNINSTALLED — The bundle has been uninstalled. It cannot move into another state.
3.0 Service Layer
This layer is concerned with interaction and communication among modules, specifically the components contained in them.
Thus to provide the interaction between bundles, services are used. Services are specified by the Java interface. Service providers (Bundles) can implement this interface and register the service with the Service Registry. Service consumers (clients) of the service can find it in the registry.
OSGi Sketch
Awesome! Now you are condensed with OSGi services, let's get our hands dirty with OSGi next.🍾 🙌 🚀
References
- OSGi in Action: Creating Modular Applications in Java- Book by David Savage, Karl Pauls, Richard S. Hall, and Stuart McCulloch
- OSGi Docs Home Page
Also published on: https://maneeshaindrachapa.medium.com/wait-what-is-osgi-1f33e8ddfb08