‘OSGi Demystified’ is a series of articles addressing common OSGi issues in CICS. We offer insight into OSGi, discuss best practices, and provide setup and configuration advice. This is the second in the series of section 1, to see the first introducing OSGi and CICS bundles, follow this link.


  • Enterprise bundle archive and their use in Liberty with OSGi bundles.
  • The different ways OSGi JVM server and Liberty embrace library bundles.
  • A quick explanation of Java and Liberty related CICS bundle parts.


OSGi bundles in Liberty: EBAs

Given that a CICS bundle is essentially a container for one or more OSGi bundle parts with each bundle part referencing an OSGi bundle, let’s double the confusion. Liberty also has a containment mechanism for OSGi bundles, called an EBA, or Enterprise bundle archive. Importantly though, EBAs aren’t just a way to deploy multiple OSGi bundles, but a way to deploy sets of OSGi bundles as a single isolated sub-system (think mini OSGi container per application). In practice that means OSGi bundles in different EBAs are not visible to each other; by intention. Using sub-systems gives Liberty the ability to isolate applications from each other for both security and integrity purposes – but that’s a topic for another day! In the meantime it should suffice to know that CICS steps up to the mark and provides an EBA bundle part for deploying EBAs to CICS Liberty. Ultimately, your OSGi bundle sits inside an EBA, and your EBA sits inside a CICS bundle. It is usually these containment mechanisms, in tandem with unqualified uses of the term bundle, that cause outbreaks of bundle sickness. Now you have a cure.

CICS bundle containing an EBA deploying into a Liberty JVM server

OSGi library bundles – not so common

Sooner or later you’ll discover that applications tend to perform a subset of similar operations. Perhaps you’ll even develop common libraries and place them in distinct OSGi bundles. Doing so would demonstrate you’ve embraced the re-usable component power of OSGi, well done! Your next challenge is to deploy them to your JVM server making them accessible from all applications and ensuring that each component, or library, is installed and ready. It’s a great plan, with only a minor catch. Despite both OSGi JVM server and Liberty embracing library bundles, they do it in very different ways.

Recall that Liberty uses an OSGi application, or EBA, to create isolated sub-systems of OSGi bundles. An EBA can contain a set of JAR files (the physical manifestation of OSGi bundles), OR it can contain a ‘shopping list’ of OSGi bundle references. That ‘shopping list’ is essentially an index into something called the bundle-repository. You can configure a bundle-repository in Liberty’s server.xml. The bundle-repository is a directory on the file-system containing one or more OSGi bundles. When the shopping list is resolved, OSGi bundles are taken from the bundle-repository, installed into a common OSGi sub-space, and our EBA is given access to them. In this way, multiple applications can share common OSGi bundles while still retaining isolation for their main function.

If you deploy an OSGi application (EBA) within CICS bundles. The CICS Explorer tooling will upload all required OSGi bundles inside the EBA (the archive file). To use the ‘shopping list’ approach you must manually develop and deploy the OSGi application (EBA) and manually configure a bundle-repository.

In contrast, the OSGi JVM server shares a single OSGi space. Each OSGi bundle deployed to the OSGi JVM server is potentially available to all other OSGi bundles that have been deployed. Whether the OSGi bundles will actually place a dependency on each other, or not, is controlled through the Import-Package and Export-Package statements in the MANIFEST file of the OSGi bundle.

Ultimately, in an OSGi JVM server any OSGi bundle can provide common function, so the OSGi JVM server has a slightly different concept for a library known as a middleware OSGi bundle. A middleware OSGi bundle is one that shares the life-cycle of the container. Middleware OSGi bundles are not deployed inside a CICS bundle. Instead, they are installed and enabled when the OSGi JVM server is enabled. Middleware OSGi bundles remain enabled for as long as the JVM server is enabled and can be configured using the JVM profile option:

OSGI_BUNDLES={comma separated list of path qualified OSGi bundles}


As promised here’s a quick explanation of Java and Liberty related CICS bundle parts. An OSGi bundle part is used for deploying a single OSGi bundle to an OSGi JVM server. Liberty doesn’t allow direct deployment of OSGi bundles. It requires a container into which one or more OSGi bundles can be placed, or referenced. We’ve discussed the EBA bundle part in passing already, and there’s not really much to add. It’s suffice to say that an OSGi application project created by your Eclipse based WebSphere Developer Tooling will be exported (JAR’d up) into an EBA. A CICS bundle can contain an EBA bundle part, and when the CICS bundle is installed into CICS, the EBA is installed into the Liberty server instance running inside your Liberty JVM server.

In similar fashion, a (Dynamic) Web Application typically created by the WebSphere Developer tooling in Eclipse (WDT), will be exported as a WAR file (Web ARchive). A CICS bundle can contain a WAR bundle part, and the Web application is deployed to Liberty when the CICS bundle is installed. Unsurprisingly that same pattern applies to the final artifact in our list, the Enterprise Archive (EAR), which has a corresponding EAR bundle part.

For the next instalment of Invoke Ivan in OSGi Demystified, follow the link to section 1.3: Bundles Continued…

Or to see others in the OSGi series by Invoke Ivan, follow this link.

Join The Discussion

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.