Java Reference
In-Depth Information
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-
ning throughout.
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.
6.2
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.
