Whiteboarding: A form of torture?

The whiteboard pattern is a pretty well-known "best practice" in the OSGi community. For this reason, I was somewhat surprised to hear from a co-worker (echoed by a couple folks at EclipseCon) that not everyone considers this pattern a blessing. Unfortunately, I have never seen this argument laid out in writing before, so I thought I would give it a shot in this blog entry--apologies if I do it no justice.

The whiteboard pattern is basically a modification on the standard listener pattern in which the content publisher looks up its consumers in the service registry instead of the consumers hooking themselves into the publisher. For a deeper understanding, there is lots of good info available including this whitepaper. This pattern purportedly works much better (fewer lines of code, less prone to error, etc.) in the dynamic world of OSGi services...so why wouldn't everyone love that?

The answer (and I suspect this is an eye-of-the-beholder thing) is simplicity. Although the code presented in the whitepaper makes it pretty clear that using the basic framework to implement the traditional listener pattern can be quite burdensome, I am not convinced it must be this way. With the improvements in service frameworks like Declarative Services, it is becoming easier and cheaper to develop a system based around service interactions. So if the programming complexity becomes similar, in what way does the whiteboard pattern introduce additional complexity?

I can say from first-hand experience that the loosely-coupled nature of OSGi services can be a dual edged sword...powerful yes, but also difficult to follow. When you step into a large project with lots of service dependencies, it can be hard to untangle the interactions and see how the pieces fit together. This effort is made even more difficult in code which uses the whiteboard pattern. The registry becomes entangled with a bunch of listener objects, which have no clear indication of who should call them or what service they are providing to the system. Additionally, the developer is expected to know that they can hook into a particular producer by implementing some standard interface and publishing it to the registry. This type of hidden interaction model can be very tricky to find and needs to be well documented to be effective...or else it can start to feel a bit too 'magical'.

The beauty of the service registry is that it gives us a single place for safe, dynamic, loosely-coupled bundle interaction. So what we would really like to see in the registry is the "service" a particular bundle is offering to the other bundles in the system. On the one hand we have a pool of content consumers offering only a "listen" service, while on the other we have a content publisher who allows you to register your interest with its content. Now which of these bundles do you think more accurately fits the average developer's notion of "service"? I wonder why we don't see this type of "whiteboard" pattern in distributed SOA systems...