Multiple top-level systems that communicate with each other via messages(events/commands).

The Main class of the program wraps around all the systems and has a message dispacher component wich delivers messages from one system to another. Each system contains a lot of objects that need to communicate with each other, however these messages do not necessarily concern other systems.

My current implementation is as follows: each registered listener has an object(hashmap) "subscribedEvents" with callbacks for the concerned events(messages), but to avoid having the inner objects of a system send their messages through the main dispacher they would have a personal dispacher. The problem I have with this approach is how to identify each dispatcher, since inner objects still need to be able to listen for top level messages and the "subscribedEvents" object would have to become


What would be a proper way to add identifiers to the dispachers? A dispatcher is just a component of a class(system or inner object) and each dispatcher is not aware of the others. I can only think of a singleton eventDispatcher factory, but that doesn't look like a very elegant solution to me.

PS: I am open to a different whole new different approach for dealing with communication, this is just what I have come up with.


1 Answer 1


You need a location service (an example of one is DNS) where each personal listener can register itself with a parent, possibly leading to those parents being children of another parent in turn until you get to a root. This allows you to broadcast messages that are received from a parent to all children that have registered to receive those messages.

If you know which dispatcher to send a message to you can send it directly, otherwise, you can ask the root to locate the one you want (I don't know your criteria for this). Alternatively you can send the message to the root and let it propagate the message to all its children, and their children. Use a location request message for this and it becomes easy to implement.

This kind of federated system works well - but be careful not to pass on all messages, you should be filtering them by allowing each dispatcher to say what kind of messages it cares about, and never send others to them. This helps make it scale. It also means you can add new services very easily, you just drop them into the system and each one starts processing messages as if by magic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.