Event Bus and event handling

Event bus is a rather simple notion, that is of great aid. Think of a telephone network; to communicate between two ends, one would require a line of communication. In most programming languages, an object reference serves this purpose. Having a line of communication between any two end-points quickly becomes a problem with a complexity of O(N^2). Simple combinatorics says we need nC2 lines i.e N(N-1)/2 lines between N unique parties.

Telephone exchanges provide a rather good solution to this. Instead of creating a line between every end-point. We create a line to the exchange for every new party. So N parties would need N lines. This is an O(N) solution, with a linear ordering. How does this look in program terms? There are several solutions, but I prefer the one describe here. I prefer distinguishing MessageSenders, MessageListeners, so I typically create two classes for each. Then I need a MessageExchange, which happens to be a listener as well as a sender. All senders speak with the exchange and all listeners listen against the exchange. The exchange broadcasts any event received to all the parties.

I have ignored one finer aspect of this pattern, The message itself. Messages are typically implementation specific. In java I prefer to use PropertyEvent. This is a generic event which takes three arguments: EventName, OldValue, NewValue. This generic nature of the event suits me really well. I tried incorporating the same philosophy in GWT. The listeners are called MessageHandlers in GWT. However, the GWT message handlers have an inherent problem ( as of GWT 2.0). Whilst an event is being processed, other handlers cannot be hooked up and hence cannot receive events. I had to rewrite the contract to fix this. More on this in the next post.