One of the most powerful features of the Java platform is the JVM's class-loading infrastructure: Having a well-defined way of acquiring, verifying, and running code contributes to the Java platform's security and predictability.

At the same time, as Java applications grew in size and complexity, the JVM's class loading infrastructure is proving inadequate for large enterprise deployment, argues Daniel Rubio in a recent article, An Introduction to OSGi on the Server Side.

According to Rubio, OSGi's origins in the severely constrained space of mobile and embedded devices is now paying dividends in the enterprise: The tasks of intelligently managing class dependency and defining a lifecycle for Java code loaded into the VM, can make enterprise application deployment more efficient:

Since OSGi's roots are in the embedded market, it should come as no surprise that OSGi's primary focus is on boosting the capabilities of the lowest common denominator in Java: The Java Virtual Machine. While the JVM has more than a decade of engineering behind it, for certain tasks—such as system services and dynamic loading—it has fallen shy of the expected curve in some vertical industries, giving way to initiatives like OSGi to fill in feature gaps...

[One such gap is] dynamic loading, a mechanism by which the building blocks of an application could be determined on the fly, limiting resource consumption to only those essential pieces required for proper operation. As it turns out, because OSGi grew out of the resource-starved embedded market, it offers precisely this: an extremely efficient way to install, start, stop, update, and uninstall modules on an as-needed basis...

At the heart of OSGi's ability to manage class loading and class dependencies is the OSGi bundle:

Once your start to explore OSGi environments, you may be surprised to learn that the same environment capable of being used on something as small as a smart phone can also be used to manage a desktop application as well as your server-side projects. The reason for this is that OSGi's deployment and programming model is equally applicable under all these different scenarios, which brings us to the most concrete part of OSGi: a bundle...

A bundle, also often referred to as a module, is the packaging format used in OSGi that contains Java classes and resources, as well as other processing instructions used by an underlying OSGi environment—a packaging that, in itself, has a structure very similar to that of a JAR file.

As it turns out, the contents of an OSGi bundle JAR file—or simply a OSGi module"which is Java classes and other application resources, are not made available via the classical Java classpath. Instead, they are delegated to an OSGi environment, which then creates a type of class loader graph aimed at resolving dependencies between all the underlying classes and resources contained in each OSGi bundle JAR file deployed onto an OSGi environment.

This concept of a class loader graph is special for a few reasons. For one, it limits the amount of Java classes and resources loaded at any single point in time during the execution of an application. In addition, by relying on a graph model, any application running within an OSGi environment can automatically create, merge, or destroy branches on an as-needed basis to fulfill class dependencies, giving way to the dynamic install, start, stop, update, and uninstall capabilities mentioned at the outset.

The rest of Rubio's article explains how OSGi's class loader graph relates to the OSGi bundle's lifecycle, and how various OSGi technologies might work together to allow easy assembly of complex applications. Rubio also provides a tutorial introduction to the Apache Felix OSGi runtime.

In your enterprise projects, how do you manage the interaction of various applications and frameworks? What role do you think OSGi can play in simplifying application development and deployment?