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

6.4 Blueprint and service dynamism

As we've been working through enterprise OSG i programming, we've said several
times that OSG i is a dynamic environment. You've even seen OSG i dynamism in action
in chapters 2 and 3. Uninstalling a bundle fragment removed translations, and stop-
ping and starting bundles made special offers appear and disappear. This dynamism is
amazingly powerful and allows OSG i applications to do things that aren't possible for
conventional applications.

6.4.1 The remarkable appearing and disappearing services

What this dynamism means is that services can come and go at any time . It's possible that a
required service isn't available when you need it. It's possible that there's more than
one potential match for the service you need. It's possible that a new service becomes
available at runtime, or that a service you're currently using goes away while you're
using it! Put like that, OSG i dynamism sounds scary. How can you write a solid pro-
gram on quicksand?
Luckily, your application is only as dynamic as you want it to be. If you have good
control over your application environment and have no need to add or remove services
on the fly and no desire to upgrade your application without restarting everything, you
can probably assume that a lot of the scenarios in figure 6.5 won't apply to you.

(a)

(b)

(c)

Figure 6.5 It's possible that (a) a required service isn't available, (b) there's more than one match for
a required service or that a new service becomes available at runtime, or (c) a service that's in use
goes away.