Starting with Digital Factory 7.0, new modules must now be written using OSGi bundles. As OSGi is a mature and powerful dynamic module system for Java, it becomes a lot easier to build full-fledged Digital Experience Manager modules that can interact with each other, while avoiding complex interdependencies that might make maintenance and deployment complex. At the same time, it makes it possible to leverage the already available OSGi bundles such as the Felix Web Console or the Felix Shell to quickly add functionality to a Digital Experience Manager installation.
What is OSGi?
OSGi (aka Open Services Gateway initiative) is a dynamic module system for Java. It is currently the most powerful and most mature dynamic module system available for Java applications. In OSGi, modules are actually called “bundles”. They are specialized JARs that include extra MANIFEST.MF entries that declare the dependencies between modules, as well as versioning and package information made available to other modules. In effect, most existing JAR can be converted to an OSGi bundle with little work (they are even automatic transformation tools available). In the OSGi runtime, only packages that are exported will be available and visible to other bundles, only if the using bundles also import them. So in effect there can be fine-grained control of accessible Java packages (as well as associated versions) between bundles.
A minimal OSGi bundle
An OSGi bundle is basically a classic Java JAR file with additional metadata information inside the META-INF/MANIFEST.MF file, such as:
- Bundle identifier (symbolic name)
- Bundle version
- Bundle package imports and exports
- (Optional) Bundle activator
Here is an example of a minimal OSGi bundle:
META-INF/MANIFEST.MF: Bundle-SymbolicName: org.jahia.modules.example Bundle-Version: 1.0
Taken from the OSGi’s official website:
From the developers point of view:
OSGi reduces complexity by providing a modular architecture for today's large-scale distributed systems as well as small, embedded applications. Building systems from in-house and off-the-shelf modules significantly reduces complexity and thus development and maintenance expenses. The OSGi programming model realizes the promise of component-based systems.
From the business point of view:
The OSGi modular and dynamic model reduces operational costs and integrates multiple devices in a networked environment, tackling costly application development, maintenance and remote service management.
The key reason OSGi technology is so successful is that it provides a very mature component system that actually works in a surprising number of environments. The OSGi component system is actually used to build highly complex applications like IDEs (Eclipse), application servers (GlassFish, IBM Websphere, Oracle/BEA Weblogic, Jonas, JBoss), application frameworks (Spring, Guice), industrial automation, residential gateways, phones, and so much more.”
Despite an initial learning curve that requires learning how to setup OSGi modules properly (especially their dependencies), OSGi benefits quickly make themselves visible in even small projects.