superstore's persistence layer? You had an in-memory database that continued run-
ning throughout. You didn't even lose your HTTP session because the WAB was run-
WARNING: DISMANTLE WITH CARE Just because you can remove parts of a run-
ning OSG i application, doesn't mean it always ends well! Your application
must be written to cope safely with things appearing and disappearing. How
to do that is the subject of this chapter.
Fixing the superstore was a powerful example of how OSG i's dynamism can be used.
You were able to apply a critical fix to your running application without stopping it.
This is one of OSG i's lesser-known features, but it's the sort of thing that makes admin-
istrators squeak with joy. Your dynamic fix was only possible because you followed the
good modularity practices described in section 5.1, keeping your bundles small and
focused. If your persistence logic had been mixed in with your web layer, or imple-
mentation details had bled through, it wouldn't have been possible. Good modularity
on its own isn't enough—you also had to follow good patterns for dynamism in the
superstore's design, handling the dynamic nature of the OSG i services you used to
communicate between bundles.
Using OSGi services
Although services are an excellent way to decouple bundles from one another, they're
essential in a dynamic system. As you saw in the persistence layer of the superstore, ser-
vice implementations can be replaced at runtime without even restarting the applica-
tion. If implementation classes had been hardcoded, on the other hand, replacing
one implementation with another would have required a complete recompile, as well
as a restart.
The value of the Service Registry
One school of thought says that OSGi services are the most useful features of the
entire OSGi specification, more valuable even than modularized classloading and ver-
sioning. In our opinion, it's rather difficult to separate the two, although there have
been a number of recent attempts to bring the OSGi Service Registry to Java SE, such
Registry has value, but without the underlying module lifecycle and classloading we
can't help but feel that there's something missing. Equally, if you were to take the
Service Registry out of OSGi, then you'd take many of the valuable usage patterns
with it. Projects like pojosr are an excellent way to shrink the gap between Java SE
and OSGi. We just hope that people don't end up missing out on the real value of
OSGi, thinking that OSGi is Java SE with a Service Registry.