Will the real whiteboard pattern stand up?
Posted on July 29, 2008
by Tommy McGuire
The OSGi Alliance white paper, "Listners Considered Harmful: The "Whiteboard" Pattern", describes the whiteboard pattern as:
...Instead of having event listeners track event sources and then register themselves with the event source, the whiteboard pattern has event listeners register themselves as a service with the OSGi framework. When the event source has an event object to deliver, the event source calls all event listeners in the service registry.
Remarkably, the event source is not registered with the framework as a service. This makes bundles using the whiteboard pattern significantly smaller and easier to implement. The inter-bundle dependency between the event source and the event listener is handled by the framework and requires almost no code in the event source and event listener bundles.
The SpringSource Tool Suite tutorial on the whiteboard pattern describes it similarly,
The whiteboard pattern uses the service registry to decouple the interested parties. If an observer wishes to listen to events, the observer simply publishes a service that implements an agreed listener interface. The subject (or event producer) simply sends events to all registered services implementing the listener interface at the time the event is generated.
Instead of advertising the subject, and keeping state about all known observers in the subject, we advertise the observers and use the service registry itself to keep track of them.
However, an article on TheServerSide.com describes the pattern slightly differently:
Basically, the whiteboard pattern is this: a content provider registers itself into the OSGi service registry. A content consumer regularly polls the registry for consumers of the content provider type, and then calls each one in turn.
Strangely, the example code in the white paper shows the same style as TheServerSide's article: a ClockManager registers a Clock object as an OSGi service (under a ContentProvider interface). Subsequently, DisplayManager thread periodically polls the ContentProvider services and displays the content.
I would think that a straightforward implementation of the description of the whiteboard pattern would have the Displays register ContentListener interfaces, and have the Clock objects periodically publish the time to those listeners.
On the other hand, that straightforward implementation would likely be wrong. Since the display is only interested in the current state when it is being updated (the window is visible, the LCD is turned on, etc.), the implementation as shown in the paper's example avoids having the clock update the displays when they cannot do anything with the information. On the third hand, the displays could unregister their services when the window is hidden or the LCD powered off. This avoids having an extra polling thread per display.
The SpringSource tutorial wisely uses a completely different example which does seem to follow the description.
