Is OSGi the Key to Extensible Applications?

Most applications I’ve worked on needed some customization for customers, and some features had to be added or removed according to the edition they bought. That requires a degree of modularity. In the best case we designed for it from the start. In the worst case we bolted it on as we went. Java, whether Standard or Enterprise Edition, provides no official way to make applications extensible.

Broadly, there are two places to extend an application: the front end, or user interface, and the back end, or application logic. An extension might add a feature with a complex UI and its own application logic, or it might be a single class that slots in somewhere during execution. We need a system to apply the extensions. It should certainly let us manage them, and it would be nice to add them while the application is running.

From the point of view of the application’s internal architecture, we’d want the system to let us define extension points and export only selected APIs for external use. The Java Module System will solve part of this problem (seemore about the Java Module System on Dagblog), but it won’t arrive until Java 7.

If we look at products we use every day as developers, we’ll find some already handle extensibility quite well. I do mean IDEs like Eclipse or NetBeans, where extensibility has been honed almost to perfection.

Take Eclipse. The whole thing is built around OSGi, or rather an implementation of it. OSGi is a specification that defines a standard for developing, deploying and managing applications in a controlled environment. The environment is an OSGi container, and an application is called a bundle. Put simply, the container is an environment built on top of the JVM that manages how applications, or bundles, coexist, from the visibility of particular APIs to the definition of dependencies.

OSGi is divided into several layers.

Image could not be loaded. Archive image in Is OSGi the Key to Extensible Applications?, figure 1

↗ Medium

• Security. Extends the mechanisms provided by standard J2SE security. For example, it can grant access to particular services according to a bundle’s digital signature.
• Module. Handles which APIs are visible across bundles, hiding or exposing particular classes or packages.
• Life cycle. Defines what happens to bundles at runtime: adding, removing, starting and stopping them. It also defines an event API for managing bundles.
• Service. Lets you define the services a bundle integrates with. The idea is to define a service interface and hide the implementation. The bundle doesn’t depend on a particular implementation. J2EE takes a similar approach: it defines interfaces such as the Servlet API, and individual providers, such as application servers or servlet containers, implement them.
• Execution environment. The Java environment where the code actually runs.

Besides what those layers provide, the OSGi container acts as a service registry. You can look up and register services or select them by implementation. The service itself is a bundle registered in the registry. The diagram below shows how a bundle interacts with the layers of OSGi.

Image could not be loaded. Archive image in Is OSGi the Key to Extensible Applications?, figure 2

↗ Medium

OSGi has been around since 1999, when the OSGi Alliance was founded. The alliance continues to develop OSGi. The specification is now in its fourth version, covered in the JCP as JSR 291. OSGi has many implementations. Some of the most interesting open-source containers include Eclipse Equinox, Apache Felix, Knopflerfish.

Having these containers available means you can build an application architecture around OSGi, or at least consider doing so. An OSGi container is just the kind of platform that suits extensible applications. That’s probably why the following products chose OSGi, as this quote from Can Someone Tell Sun About OSGi?shows.

BEA moved their micro Service Architecture on top of OSGi, IBM Websphere 6.1 seems to have chosen OSGi, Jonas is an EE framework build on OSGi from day one, and the JBoss Microcontainer is modified to support OSGi. On top of that, we have one product that made many people re-think Java EE: Spring.

Add to that some experiments with OSGi in Struts 2 and the Equinox in a Servlet Containerproject, and OSGi seems to be making inroads in enterprise software. It’s early days, so we can hardly expect interoperability across a wider range of enterprise technologies, such as EJB.

If JSR 291 could somehow be squeezed into J2EE 6, as some are actively speculating, it would be a big step toward making OSGi a way to write extensible applications across the Java platform. Unfortunately, efforts around OSGi and its standardization in Java are running into political pressure from Sun over the rival JSR 277, the Java Module System.

Time will settle the situation between JSR 277 and JSR 291. If you want to write extensible applications right now, OSGi is at least worth a look.

Related articles

• Status of Opensource OSGi containers (a very good comparison)
• Comparison of JSR 277 and JSR 291 features
• Eric Newcomer on the future of OSGi
• Spring OSGi specifiaction