Java Reference
In-Depth Information
REGISTRATION LISTENERS
Usually, when services appear and disappear, it's the users of the service that need to
be notified. But the services themselves can be notified of their registration and
unregistration using a
registration listener
. Remember that a service being registered is a
necessary prerequisite for anyone to be able to consume it, but it's not the same thing
as it being consumed. Just because a service is registered doesn't mean it's used by
someone, or ever will be.
Why would you want to know if a service has been registered and unregistered?
Notification of unregistration has a clear use case for teardown and tidy-up. An unreg-
istration listener can serve the same function as a Java finalizer, but without the issues
of finalizers.
There are fewer uses for service registration listeners, but they can sometimes be
useful for initialization. If nothing else, they're handy for tracing the dynamics of your
system!
6.5
Summary
OSG
i services are sometimes described as a replacement for conventional Java facto-
ries. You've seen in this chapter that services can do an awful lot of things that facto-
ries can't—they can come and go, they can be managed at runtime, they can be
filtered using properties, and they form the basis of a handy pattern for handling
event notifications.
The dynamism of
OSG
i services isn't without its downside; in their raw form, regis-
tering them is a little verbose, and accessing them, if done in a safe way, is extremely
verbose. Blueprint and other dependency injection frameworks neatly eliminate these
issues. They make providing services easy and insulate applications from the dyna-
mism of services. Perhaps most conveniently, Blueprint manages dependency chains
so that services (and ordinary Blueprint beans) only become available when all their
dependencies are present; if services go away, the services that depend on them are
automatically unregistered.
