Java Reference
In-Depth Information
Why whiteboards?
If you struggle to get the whiteboard pattern first time 'round, you're not alone. One
of the most puzzling things about the whiteboard pattern is its name! The idea behind
the name, apparently, is that the Service Registry acts a bit like a whiteboard in an
office. People can subscribe to an event—a picnic, say—by adding their name to the
shared whiteboard. They don't need to contact the picnic organizer directly, or even
know who's organizing the picnic.
At first, the whiteboard pattern can seem backward. After all, surely it's the event
source that's providing the useful service, and the listeners that benefit from the ser-
vice, right? The event source doesn't need any of its listeners, but the listeners need
the event source a great deal!
The thing to do is think less about the
service
part of the Service Registry and more
about the
registry
part. The Service Registry, in combination with Blueprint, is a handy
general-purpose registry. By using the Service Registry to collect your listeners you
dramatically reduce the complexity of your event source. You also don't have to worry
about what happens when listeners are stopped; the Service Registry elegantly ensures
that you only ever see services from running bundles. When you get used to the white-
board pattern, you'll find that it can be used to simplify many different situations. It
even crops up when writing remote services, as you'll see in chapter 10.
The whiteboard pattern is most effective when you want the same event, or the
same processing, to occur multiple times. This could involve calling a number of lis-
teners, counting up a number of objects, or even reacting to the presence and
absence of particular services. You've been using the whiteboard pattern in the Fancy
Foods online superstore since chapter 3; rather than registering each of the depart-
ments in your superstore with the business beans, you expose them as services, and let
the business beans look them up as necessary. This is part of what makes the super-
store so simple to extend.
Taking full advantage of
OSG
i doesn't just means changing how you think about
low-level patterns like factories and listeners. You may also need to have a bit of a
rethink about some of your habits for structuring enterprise applications.
5.3
A better enterprise application architecture
If you're used to writing Java
EE
applications, you probably have a toolkit of application
architectures and development patterns you're in the habit of using. Many of the pat-
terns that work well for Java
EE
applications work equally well for enterprise
OSG
i ones.
How do these Java
EE
patterns translate in the dynamic world of
OSG
i? Some work
pretty much unchanged. For example, you'll probably want a business tier, a presenta-
tion tier, and a data access tier. But some of the familiar Java
EE
patterns need a bit of
rework to make the most of
OSG
i's modularity and dynamism, and there are some new
patterns in enterprise
OSG
i.
