Building dynamic applications with OSGi services - Enterprise OSGi in Action - page 133

One of the key enablers of OSG i dynamism is OSG i services. Services form the basis
of an extremely powerful programming model, and OSG i's dependency injection
frameworks extend that programming model to make it simple to use, too.
In this chapter, we'll discuss how OSG i dynamism works and how to get the most
out of it. We'll also cover in detail how dependency injection and services can be used
to handle dynamism with as little work as possible.
We'll start by looking more closely at what dynamism means for OSG i applications.

6.1 OSGi dynamism

One of the defining characteristics of OSG i is its dynamism. This dynamism was criti-
cally important in the environment for which OSG i was originally conceived: embed-
ded devices. How does it play out in the enterprise space? Many of the concerns of
enterprise applications are surprisingly similar to those of embedded ones; modules
may be deployed to a variety of different environments, and those environments
might change over the lifetime of the module, as other devices (in the embedded
case) and components (in the enterprise case) come and go.
We first introduced the concept of dynamism way back in chapter 1, so far back
that you might not remember it now. Since then we've covered a lot of ground, some
of it making use of OSG i's dynamism without calling it out. Going back to chapter 1,
we discussed how in OSG i bundles can be started and stopped and even uninstalled
from a running OSG i framework. This is the core of OSG i's lifecycle model, and ties in
closely with dynamism.
In OSG i, ACTIVE (that is, started) bundles are roughly equivalent to what Java EE
developers would think of as running modules. In Java EE , running modules can load
classes and have managed objects such as servlets or EJB s available for use by clients.
In OSG i, things are similar: ACTIVE and STARTING bundles can load classes and
expose services in the Service Registry. (A bundle may be in the STARTING state
either because its bundle activator is still being run, or because the bundle has cho-
sen lazy activation and none of its classes have been loaded.) Importantly, OSG i bun-
dles have other states; you may remember that RESOLVED bundles can still load
classes, but are not able to register services. If a bundle is stopped, then all of its ser-
vices are unregistered. This has an important consequence for other bundles;
because services can come and go, it's possible that a service you're using may cease
to exist. Clearly your code might still have an object reference to call, but it's impor-
tant to stop using it because its behavior is no longer guaranteed. The stopped bun-
dle will have lost access to any services it was using, and will probably also have done
some tidy-up to free up resources.
The most surprising difference between Java EE and OSG i is that, in OSG i,
modules can be completely removed from a running system or added to it. Can
you imagine removing an EJB JAR from a running EAR without stopping the other
EJB JAR s and WAR s? Doing this in OSG i is surprisingly easy; if you've been following
our examples, then you've already done it! Do you remember fixing a bug in the