This series of section #1 articles major on OSGi bundles and OSGi services. OSGi application and architectural guidance is given, alongside a round-up of useful materials.
1.0 OSGi bundles
As with all paradigm shifts, it can take a certain amount of education and persistence to gain advantage from a new technology. So if you are confounded by Java, bemused by bundles, up-in-arms over OSGi then read on. Let’s face it, the alternative could be that you become irrelevant, left-behind, or even obsolete. We don’t want that.
If you are confident and raring to go, by all means install CICS Explorer, add the Java/Liberty component, write some Java code, create an OSGi bundle, and deploy your application to CICS. For the rest of us, consulting the product documentation is a good start, see CICS Java support – just in case there is something there of use. You’ll be needing this page too, CICS Java troubleshooting, it’s the troubleshooting guide for OSGi JVM servers.
OSGi (Open Services Gateway initiative) is a Java framework for developing and deploying modular software programs and libraries. The modular components of OSGi are known as OSGi bundles. Each OSGi bundle, is a tightly coupled, dynamically loadable collection of classes, jars, and configuration files. Each OSGi bundle explicitly declares the packages they provide, and the packages they require.
By enforcing explicit declarations, the OSGi framework can provide a powerful component model. Beyond the obvious benefits of componentisation and re-use, the framework uses install-time dependency resolution to help avoid run-time failures. OSGi also offers a powerful versioning mechanism where multiple versions of the same class can exist within the same JVM. Improved class loading performance is realised as a result of the clearly defined dependencies, and a dynamic service architecture allows applications to be updated without a server restart.
In CICS, the OSGi JVM server is a Java runtime that incorporates an OSGi framework. That same technology is used for the Liberty JVM server. The key difference between the two is that the Liberty JVM server embeds an instance of a Liberty server. Typically an OSGi JVM server is appropriate when Java SE APIs are required, and a Liberty JVM server is appropriate where Web technology and/or Java EE APIs are required.
With the formalities out of the way, let’s move on to some clarifications.
OSGi bundles are not CICS bundles
That’s not a backronym by the way! You’ll be surprised how often these two types of bundle can be confused. CICS bundles are a package and deployment mechanism for CICS resources, while OSGi bundles are components of the Java/OSGi system.
Now that distinction is clear in your mind, let’s add some confusion. CICS bundles contain one or more resources called bundle parts. OSGi does not have any notion of ‘parts’, so throughout this text ‘bundle part’ will always refer to a CICS bundle part. There are a number of bundle parts relevant to CICS Java and Liberty, and we’ll discuss the Liberty related bundle parts that correspond to WAR, EAR, and EBA in the next instalments. For the moment, let’s concentrate on the pure OSGi solution, and that means the OSGi bundle part in an OSGi JVM server. It should be no surprise to learn that the OSGi bundle part allows CICS to deploy an OSGi bundle into an OSGi JVM server when the CICS bundle is enabled. OSGi environments outside of CICS have no concept of CICS bundles, so OSGi bundles in the wild are generally deployed directly to the OSGi framework. The CICS approach offers additional benefit though, like the ability to control the life-cycle of both OSGi bundles and CICS resources within the same packaging mechanism. See below:
Now that a CICS bundle is clear, let’s move onto OSGi bundles in the next instalment of Invoke Ivan’s OSGi Demystified: Bundles in Liberty.
To see more Invoke Ivan blogs on the topic of OSGi, see the collection here.