OSGi Architecture

The OSGi framework is a module system and service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments. Intalio|Cloud makes extensive use of the OSGi technology.

By Hugues Malphettes and Antoine Toulme, Intalio — May 2010

Introduction

According to Wikipedia, OSGi enables applications or components (coming in the form of bundles for deployment) to be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot, while the management of Java packages/classes is specified in great detail. Life cycle management is done via APIs, which allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.

Over the years, OSGi specifications have moved beyond the original focus of service gateways, and are now used in applications ranging from mobile phones to the open source Eclipse IDE (using Intalio|Jetty). Other application areas include automobiles, industrial automation, building automation, PDAs, grid computing, entertainment, fleet management and application servers.

OSGi Component Model

By default, OSGi treats all bundles equally, unlike J2EE, where each application lives in its own silo, and for which different component models (EJB, Servlet, etc.) use different technologies to communicate with each other. As a result, J2EE makes it overly complex to write integration code or extensions to an already deployed application. Usually, integration between webapps in J2EE is achieved by exposing Web APIs and having applications exchange messages over HTTP. With OSGi, integration happens directly at the object level, and every technology available to enable the object's integration with other systems and applications is equally available to any other object.

Benefits

• Lower memory footprint by sharing common libraries across multiple components
• Lower memory footprint by deploying more applications on a single JVM
• Faster startup times by enabling lazy starts of optional components
• Easier upgrades, updates, and lifecycle management through shared component repositories
• Simpler application lifecycle management by streamlining library dependency checking
• Lower code complexity by enabling tight integration across applications
• Faster code development by leveraging a fully integrated SDK with direct access to all libraries from the debugger
• Easier bug fixing through source code access (most OSGi implementations are available under Open Source licenses)
• Faster build process through integration with Maven and Apache Buildr

Migration from J2EE

The Intalio|Jetty packaging for OSGi supports all J2EE Web applications, as well as all shared libraries and existing configuration files. All standard J2EE technologies are available, including JNDI, JSF, JSP, JTA, as well as Spring. This makes the migration of existing J2EE applications to an OSGi environment a fairly straightforward and predictable exercise. Intalio|Cloud also supports the native execution of J2EE applications.

Differences with SpringSource dm Server

SpringSource has its own tools for developing OSGi bundles, as well as its own configuration files and provisioning plans. With the SpringSource dm Server, user applications are not treated in the same manner as the bundles that run the server, also referred to as "kernel". Much like with J2EE, user applications are defined in their own silos. This initially feels safer, because such an architecture make it less likely that one user application would interfere with another, but it defeats the purpose of OSGi: smaller memory footprint, tighter integration, and less complexity, as every component is treated in the same way. This also limits the reuse of libraries, and makes it harder to build integration code between applications.

Bundles in the SpringSource dm Server are deployed through a proprietary technology that re-writes manifests on the fly. The SDK, product exports, and upgrade mechanisms are also specific to the SpringSource dm Server. Furthermore, the SpringSource dm Server does not provide any proper upgrade framework. Instead, it manages upgrades by manipulating files directly, without using any technology that would be aware of dependencies between bundles.

Intalio|Jetty addresses these limitations by fully embracing the OSGi philosophy, and making no distinction between server components and user applications. It also leverages the standard Eclipse IDE and supports standard bundle export formats. Furthermore, it provides a fully automated upgrade framework that dynamically checks dependencies between bundles, thereby dramatically streamlining the lifecycle management of applications. To make a long story short, Intalio|Cloud would not exist without OSGi and the implementation provided by Intalio|Jetty.

Additional Resources

For more information, please refer to the following articles:

• OSGi — Wikipedia
• Class Loader Architecture Comparison – Java, J2EE and OSGi — Shylendra Bhat
• Whitepaper: Component Oriented Development and Assembly with Equinox — The Eclipse Foundation