C H A P T E R 1 2
■ ■ ■
OSGi and Spring
OSGi and Spring are, in many ways, a very natural technology combination. They approach different
problems from different directions, but they do so in a similar spirit. It's only natural, then, that
SpringSource, the company that stewards the Spring framework, should turn its eye to OSGi.
OSGi—which was formerly known as the Open Services Gateway initiative, though the name's
obsolete now—has its roots in the embedded space, where dynamic service provisioning is far more
important than it is in the gridiron world of enterprise applications. It provides a services registry as well
as an application life-cycle management framework. Beyond this, OSGi provides such features as
granular component visibility via a highly specialized class-loading environment, service versioning and
reconciliation, and security. OSGi provides a layer on top of the JVM's default class loader. The
deployment unit for OSGi is a bundle, which is essentially a jar with an augmented MANIFEST.MF . This
manifest contains declarations that specify, among other things, on what other services the bundle
depends, and what service the bundle exports.
OSGi has gained some notoriety because of Eclipse, which uses it for the plug-in model. This is a
natural choice, because Eclipse needs to allow plug-ins to load and unload, and to guarantee that certain
resources are made available to plug-ins. Indeed, the hope of an enhanced “module” system for Java has
loomed large for many years, manifesting in at least a few JSRs: JSR-277, “Java Module System,” and
JSR-291, “Dynamic Component Support for Java SE.” OSGi is a natural fit because it's been around for
many years, matured, and has been improved on by many more vendors still. It is already the basis of
the architecture of a few application servers.
OSGi is important today, more than ever, in the enterprise space because it represents a solution
that can be gracefully layered on top of the Java Virtual Machine (JVM) (if not existing application
servers) that can solve problems frequently encountered in today's environments. “ .jar hell,” the
collision of two different versions of the same jar in the same class loader, is something most developers
have encountered. Application footprint reduction provides another compelling use of OSGi.
Applications today, be they .war or .ear , are typically bundled with numerous .jars that exist solely to
service that application's requirements. It may be that other applications on the same application server
are using the same jars and services. This implies that there are duplicated instances of the same
libraries loaded into memory. This situation's even worse when you consider how large typical deployed
.wars are today. Most .wars are 90% third-party jars, with a little application-specific code rounding out
the mix. Imagine three .wars of 50 MBs, or 100 MBs, where only 5 MBs are application-specific code and
libraries. This implies that the application server needs to field 300 MBs just to meet the requirements of
a 15-30 unique MBs. OSGi provides a way of sharing components, loading them once, and reducing the
footprint of the application.