Java Reference
In-Depth Information
don't need to do anything yourself; indeed, many bundle activators have empty
stop() methods. But sometimes it's prudent to unregister a service yourself. Perhaps
you've received a hardware notification and need to tell bundles not to use your ser-
vice. Perhaps you need to perform some processing before shutting down and don't
want bundles using your service while this is going on. At times like this, remember
that you're in control, and it's often better to be explicit than to rely on the frame-
work to clean up after you.
After that salutary message, let's finish this section with a modularity topic that
has caused a lot of heated discussion on OSG i mailing lists: where to package service
interfaces.
4.5.5
Should I bundle interfaces separately?
Service interfaces are by definition decoupled from their implementations. Should
they be packaged separately in their own bundle or duplicated inside each implemen-
tation bundle? OSG i supports both options, because as long as the metadata is correct,
it can wire the various bundles together to share the same interface. But why would
you want to copy the interface inside each implementation bundle? Surely that would
lead to duplicated content.
Think about deploying a set of services into a framework. If each service has both
an API and an implementation bundle, that doubles the number of bundles to man-
age. Putting the interface inside the implementation bundle means you need to pro-
vide only one JAR file. Similarly, users don't have to remember to install the API —if
they have the implementation, they automatically get the API for free. This sounds
good, so why doesn't everyone do it?
It comes down to managing updates. Putting interfaces inside an implementation
bundle means the OSG i framework may decide to use that bundle as the provider of
the API package. If you then want to upgrade and refresh the implementation bundle,
all the consuming bundles will end up being refreshed, causing a wave of restarting
bundles. Similarly, if you decide to uninstall the implementation, the implementation
classes will be unloaded by the garbage collector only when the interface classes are
no longer being used (because they share the same class loader).
In the end, there's no single right answer. Each choice has consequences you
should be aware of. Just as with other topics we've discussed—service visibility, service
factories, and using unget and unregister—you need to know the possibilities to make
an informed choice. We'll come back to this topic in the next chapter, because pack-
aging service interfaces with the implementation bundle also requires you to define
the bundle metadata a little differently. Whatever you decide, we can all agree that ser-
vices are an important feature of OSG i.
4.6
Standard services
Services are such an important feature that they're used throughout the OSG i speci-
fication. By using services to extend the framework, the core API can be kept lean
Search WWH ::




Custom Search