OSGI
First let’s see what OSGi stands for. OSGi stands for Open Services Gateway Initiative. This basically provides an architecture for developing and deploying modular applications and libraries in Java, dynamically.
In a modular application, the classes in it will be encapsulated within the logical boundary of the module. The classes exposed to the external use and classes imported externally shall be defined within <Export-package> and <Import-package> tags of the module pom file respectively. If this didn’t give you much of an idea, it will be discussed in the later part.
<project xmlns="https://maven.apache.org/POM/4.0.0"...>
<groupId>org.wso2.mbp</groupId>
<modelVersion>4.0.0</modelVersion>
<artifactId>sample01</artifactId>
<version>1.0.0</version>
<packaging>bundle</packaging>
<name>Sample01</name>
<description>A Simple Bundle which print "Hello World" and "Goodbye World"</description>
<url>https://www.wso2.org</url>
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>1.4.0</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>${pom.groupId}.${pom.artifactId}</Bundle-SymbolicName>
<Bundle-Name>${pom.name}</Bundle-Name>
<Bundle-Version>${pom.version}</Bundle-Version>
<Bundle-Activator>org.wso2.mbp.sample01.Activator</Bundle-Activator>
<Private-Package>org.wso2.mbp.sample01</Private-Package>
</instructions>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.osgi.core</artifactId>
</dependency>
</dependencies>
</project>The above code snippet is from the pom.xml of the sample01 module, where it includes the information about the project and configuration details used by Maven to build the project.
Based on these instructions in the pom file, the bundle plugin decides the classes and resources which should be copied to the bundle at the build. The configurations of the pom file will be discussed below.
<packaging>bundle</packaging>, configure the maven to build an OSGI bundle.
Then the exporting and importing of packages will be discussed below.
Using the Export-Package instruction the list of packages to be exported can be specified. The exporting of packages from the bundle will be dependent on the pattern of the value.
<Export-Package>org.wso2.mbp.echo</Export-Package>
The classes inside the above package will be copied to a target bundle.
<Export-Package>org.wso2.mbp.echo.*</Export-Package>
The classes inside the above package and classes inside all the sub packages will be copied to the target bundle.
<Export-Package>org.wso2.mbp.echo.*,!org.wso2.mbp.echo.string</Export-Package>
“Since the list of packages is ordered, earlier patterns take effect before later patterns. Therefore all the packages that matched with the pattern org.wso2.mbp.echo.* are selected to include the target bundle. The second pattern has no effect since org.wso2.carbon.mbp.echo.* packages have been selected to include. The correct way to achieve the intended result is to change the order of the patterns.”
When the classes in a bundle refer to classes in other bundles it should be specified using the Import-Package instruction. The default vale of this instruction is “*”. The patterns of the values and its behaviors are as follows.
<Import-Package>org.wso2.mbp.exportsample.*</Import-Package>
Import classes in the package org.wso2.mbp.exportsample and all its sub-packages.
<Import-Package>!org.wso2.carbon.ui,org.wso2.mbp.exportsample.*</Import-Package>
Using a negation pattern, it is possible to remove an unwanted import of org.wso2.carbon.ui package.
<Import-Package>
org.wso2.mbp.exportsample.*,
org.wso2.carbon.ui;resolution:=optional
</Import-Package>
Resolution directive is used to indicate that package org.wso2.carbon.ui is optional. This bundle can successfully resolve even if the org.wso2.carbon.ui is not present. The default value of the resolution directive is “mandatory”.
Now let’s try to understand the OSGi Framework.
The OSGI Service Platform is composed of two halves as OSGi framework and OSGi standard services. The framework provides the OSGi functionality while the OSGi standard services define reusable APIs for common tasks.
The OSGi framework has a layered architecture as follows.
Before diving deep into the layers, if a small introduction is given on each area shown in the diagram, bundles are normally JAR components with extra manifest headers, service layer connects bundles in a dynamic way, Service Registry is an API for management services, Life Cycle is an API for life cycle management for bundles and the Modules layer defines encapsulation and declaration of dependencies.
Now let’s discuss Bundles , Service and Life cycle layers.
Bundles layer
As described above, an OSGI application consists of multiple bundles which export and import packages etc. An OSGI bundle is a JAR file with extra metadata. Therefore, when a jar file is converted to a bundle the meta data should be added for a MANIFEST.MF file.
Service layer
The service layer provides the interaction between the bundles.
Lifecycle layer
The lifecycle layer provides the run-time module (bundle) management.
The life cycle states can be identified as follows,
INSTALLED — The installation has been completed successfully. However, dependency or class loading is not done at this state.
RESOLVED — When the OSGI resolves and satisfies the dependencies and makes class loading operations.
STARTING — When the start method of the Activator of the bundle is called
ACTIVE — The start method has run successfully and the bundle is successfully started and running.
STOPPING — When the stop method of the Activator of the bundle is called.
UNINSTALLED — When a bundle is removed from the system.
The list of existing bundles can be checked as follows when the servers are run in OSGI mode. Bundle ID, State and Bundle symbolic name of all the bundles are shown.
osgi> ss
Framework is launched.
id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.0.v20080605–1900
1 RESOLVED helloworld_1.0.0
In a case where a bundle is not activated, the bundle can be diagnosed using the following command. It will show the list of missing imported packages.
osgi> diag <bundle-id>
Hope this will be helpful to understand the basics of OSGI!
References
https://piraveenaparalogarajah.medium.com/osgi-in-a-nutshell-aafc3a86cff0
https://wso2.com/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin/
