Java Reference
In-Depth Information
Discover
Listener
Event source
Service
registry
Figure 4.7
Whiteboard pattern
One downside of the whiteboard pattern is that it may not be clear that listeners
should register a particular interface with the registry, but you can solve this by high-
lighting the interface in the event source's documentation. It also introduces a depen-
dency to the service framework, which you may not want for components that you
want to reuse elsewhere. Finally, the service registry must be able to scale to large
numbers of services, for situations where you have lots of sources and listeners.
4.1.4
When not to use services
Another way to decide if you should use services is to consider when you
wouldn't
want
to use them. Depending on the service framework, overhead may be involved when
calling services, so you probably don't want to use them in performance-critical code.
That said, the overhead when calling a service in
OSG
i can be next to zero. You may
have a one-time start-up cost, but calling a service is then just a direct method call. You
should also consider the work required to define and maintain the service contract.
There's no point in using a service between two tightly coupled pieces of code that are
always developed and updated in tandem (unless of course you need to keep choos-
ing between multiple implementations).
4.1.5
Still not sure?
What if you're still not sure whether to use a service? Fortunately, you can use an
approach that makes development easier and helps you migrate to services later:
pro-
gramming to interfaces
. If you use interfaces, you're already more than halfway to using
services, especially if you also take advantage of dependency injection. Of course,
interfaces can be taken to extremes; there's no point in creating an interface for a
class if there will only ever be one implementation. But for outward-facing interaction
between components, it definitely makes sense to use interfaces wherever possible.
What have you learned? You saw how inter faces reduce coupling and promote faster
development, regardless of whether you end up using services. You also saw how services
help capture and describe dependencies and how they can be used to switch between
different implementations. More importantly, you learned how a service-oriented
approach makes developers think more about where work should be done, rather than
lump code all in one place. And finally, we went through a whole section about services
without once mentioning remote or distributed systems.
Is
OSG
i just another service model? Should we end the chapter here with an over-
view of the
API
and move on to other topics? No, because one aspect is unique to the
OSG
i service model: services are completely dynamic.
