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

The meaning of OSGi
Because of its embedded origins, the acronym OSGi used to stand for Open Services
Gateway initiative . Now, if you didn't already know what OSGi was about, the phrase
“Open Services Gateway initiative” doesn't shout “dynamic module system for Java.”
The name is so divorced from what OSGi is used for today that the original expansion
of the acronym has been abandoned, and OSGi now stands for, well, OSGi.
technology designed for the tiniest Java installations should be such a good fit for the
largest ones. Do the software running a car stereo and the software in an enterprise
application server have much in common? As it happens, yes. What embedded
devices needed was modularity and dynamism; software with large codebases has the
same requirements. Despite the huge increase in processing power and memory
available to modern devices, OSG i is, if anything, even more useful in these big sys-
tems. The increasing complexity of software projects is a key driver for OSG i adoption
in Java applications.
Until recently, desktop applications suffered from neither the level of constraint of
embedded systems nor the complexity of hefty middleware systems. In these environ-
ments the advantages of OSG i are sometimes viewed as insufficient when compared to
its perceived drawbacks.
OSGI—BAD PRESS AND POOR UNDERSTANDING
During its lifetime, OSG i has suffered from some misconceptions and rather poor
press. One of the big hurdles initially for OSG i was the perception that it was purely a
technology for the embedded market, and that it was not needed, not useful, and,
worst of all, a hindrance in the desktop and server space. This perception is clearly
wrong, and was proved so when the Eclipse runtime chose to use an OSG i framework
as its basis. It should be noted that Eclipse initially didn't believe an OSG i platform
would be suitable, but were later convinced by the huge increases in startup speed,
reduced footprint, and complexity management offered by OSG i.
Despite OSG i's success in Eclipse, OSG i is still perceived by many as being “too com-
plex” for use in normal Java applications. Although OSG i metadata is simple, it isn't
part of base Java. This means that even experts in Java are usually novices in the use of
OSG i. Further, the OSG i classloading model is significantly different from base Java
and requires developers to understand the dependencies that their code has. This is,
in general, good practice but it's also something that developers aren't used to. Partic-
ularly with established projects, retro-fitting modularity by unpicking entangled
dependency graphs can be pretty daunting. The change of mindset in OSG i doesn't
always come easily, with the result that many people write OSG i off as too hard to be
useful. While this may seem a little short-sighted, there are real reasons why OSG i feels
excessively complex, particularly when applications try to make use of existing open
source libraries.