Java Reference
In-Depth Information
application, then there's more information about them in appendix A, but we find
that we don't usually need them in our applications.
Being flexible about what service gets used can feel uncomfortable at first. How
can you possibly test your code (it's possible—wait until chapter 8)? What happens if
the provided service turns out to be terrible? What if it doesn't do what you need?
Nonetheless, it's best to trust the application deployer and leave the decision about
what service gets used to deploy time, rather than trying to specify everything at devel-
opment time. It can be hard to give up control, but being service-oriented and loosely
coupled means—well, just that!
SERVICES AND STATE
Holding much state in services presents some problems. An injected service may be
transparently swapped for another implementation if the original service goes away,
or if a higher-ranked service comes along. More fundamentally, a bundle can be
restarted or upgraded at any time, which destroys state. Persisting data is so easy that
you should consider using a persistence bundle or data grid to ensure that informa-
tion survives.
If it's absolutely essential that your services store state, all isn't lost. After all, in
many realistic application environments the system is, by design, stable—services
won't
be dynamically swapped out or bundles arbitrarily bounced, even though such things
are possible in principle.
As a starting point, you'll almost certainly want to use the prototype scope for
beans that represent stateful services, rather than the singleton scope. The prototype
scope ensures each bundle that uses the service gets its own instance (though a bun-
dle will get the same instance if it does more than one lookup). Don't forget that
using prototype scope can have scalability implications.
The prototype scope ensures no service instance is being used by more than one
bundle, but it doesn't solve the problem of more than one service instance being used
by the
same
bundle. Ultimately, even in a relatively stable system, nothing can stop a
service instance from going away if an unexpected catastrophe occurs. (We've been
imagining a mischievous cat sneaking into the ops center and walking all over the key-
board, disabling parts of the system, but feel free to invent your own entertaining
mental pictures!)
If you're programming defensively, you'll protect yourself against the disappear-
ance of stateful services, even if such things are extremely unlikely. (The system is sta-
ble, maintenance is done in scheduled downtime windows, and you keep a dog in the
ops center.) Nothing can get the stateful service back after it's gone, but as long as you
can detect the disappearance, you can initiate data recovery procedures or throw an
exception to indicate a catastrophic event.
Both the core
OSG
i programming model and Blueprint allow you to closely moni-
tor the lifecycle of services. Not only does this allow you to be confident that your
stateful services aren't disappearing, it has a variety of other uses, particularly for ser-
vices that are optional.
