OSGi and the enterprise—why now? - Enterprise OSGi in Action - page 9

Unfortunately for Java EE , there's no basic Java modularity to fall back on; the
modules within a Java application often spaghettify between one another, and inevita-
bly their open source library dependencies have to be packaged within the applica-
tions. To improve cost effectiveness, each server in a Java EE environment typically
hosts multiple applications, each of which packages its own dependencies, and poten-
tially requires a different implementation of a particular enterprise service. This is a
clear recipe for classpath hell, but the situation is even worse than it first appears. The
Java EE application servers themselves are large, complicated pieces of software, and
even the best of them contain a little spaghetti. To reliably provide basic functions at
low development cost, they also depend on open source libraries, many of the same
libraries used by the applications that run on the application server! This is a serious
problem, because now developers and systems administrators have no way to avoid the
conflict. Even if all applications are written to use the same version of an open source
library, they can still be broken by the different version (typically undocumented) in
the underlying application server.

1.2 OSGi to the rescue

It turned out that a number of core Java's modularity problems had already quietly
been solved by a nonprofit industry consortium known as the OSG i Alliance. The OSG i
Alliance's original mission was to allow Java to be used in embedded and networked
devices. It used core Java constructs such as classloaders and manifests to create a sys-
tem with far more modularity than the core Java it's built on.
OSG i is a big subject. Entire topics are dedicated to it—including this one! This
section reviews the basics of OSG i at a high level, showing how OSG i solves some of the
fundamental modularity problems in Java. We also delve into greater detail into some
aspects of OSG i which may not be familiar to most readers, but which will be impor-
tant to understand when we start writing enterprise OSG i applications. We explain the
syntax we use for the diagrams later in the topic. This section covers all the important
facts for writing enterprise OSG i applications, but if you're new to OSG i, or if after
reading it you're bursting to know even more about the core OSG i platform, you
should read appendixes A and B. We can't cover all of OSG i in two appendixes, so
we'd also definitely recommend you get hold of OSG i in Action by Richard Hall, Karl
Pauls, Stuart McCulloch, and David Savage (Manning Publications, 2011).
In a sense, OSG i takes the Java programming model closer to an “ideal” program-
ming model—one that's robust, powerful, and elegant. The way it does this is by
encouraging good software engineering practice through higher levels of modularity.
These, along with versioning, are the driving principles behind OSG i. OSG i enables
abstraction, encapsulation, decomposition, loose coupling, and reuse.

1.2.1 Modularity, versioning, and compatibility

OSG i solves the problems of sections and in one fell swoop using an incredibly simple,
but equally powerful, approach centered around declarative dependency manage-
ment and strict versioning.