First implementation of minimal Broker API

As I see it I partially agree with both Bernd and Daniel. The first thing that came to my mind is that I don't like the class name. The brokering part refers just to a fraction of the class responsibilities, which is the registration of message handlers and the dispatching. The publishing part doesn't have anything to do with brokerage. Furthermore, when I read broker I thought of something way more complex, like the broker component of a fully fledged MQ framework.

I'd vote for separating this class in two: Subscriber and Publisher and still keep the handler registry and message dispatching in the Subscriber object. As Daniel defended, I'm also more lean to leave routing and intelligent messaging mutiplexing to the applications, as this requires message inspection and there's no easy generic way to accomplish it I can think of.
Ideally, chosing the message types carefully (e.g., not combining logically separate events in the same message), using a Subscriber per source, and the message handlers should be sufficient for that purpose.

At the implementation level there's a good reason for separating the object in two that derives from ZeroMQ threading restrictions. ZeroMQ sockets can be used only by the thread that created them. I think this class will be difficult to use if the same thread has to do both publish and receive. In the end the client code will tend to use a Broker for just one purpose (puslish or subscribe) to workaround this requirement, effectively using it as a two-face class with functionally and de-facto separated interfaces.