Confusion about Message Bus / Command Dispatcher patterns
Recently I've been reading a lot about distributed messaging and associated patterns. I used some of them supported by the tools like for exemple NServiceBus.
Many of those patterns are described on internet. Some of them I recently read was :
- Message Broker : http://msdn.microsoft.com/en-us/library/ff648849.aspx
- Message Bus : http://msdn.microsoft.com/en-us/library/ms978583.aspx
- Messaging patterns in SOA : http://msdn.microsoft.com/en-us/library/aa480027.aspx
- Udi Dahan's post about differences : http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences/
If using such tooling as NService bus alows to do a lot without thinking to much about infrastructure problems, some questions have araised when I tried to implement a basic Message Bus and command handler. In fact when it comes to these patterns I can't see many differences between them.
I won't paste code because it's to long but I found two blog posts that quite describe the idea of implementation I would like to talk about.
The idea is simple, the message bus tracks the subscribers and dispatches the messages to different subscribers if they are interested in.
- Command Handler : http://weblogs.asp.net/shijuvarghese/archive/2011/10/18/cqrs-commands-command-handlers-and-command-dispatcher.aspx
It's quite similar to message bus. The command bus invokes the command handlers for a given command type.
So in both cases there are similarities.
What are the real differences and benefits using one pattern than another (I'm not talking about supporting tooling). What I'm missing ?
The second question is. Does the message bus is valuable without the supporting tooling ? I don't see myself to impelment the support for all tenents on my own.
I'm sorry for a long and confusing question but don't hesitate to ask for more details.
Answer
Woah, it'll be tough to give an answer more thorough or more credible than the MSDN you linked to, so lets go for more concise.
A Message Bus is concerned with communication. It doesn't even require that the communication be delivered is a command or not. It also doesn't care what the payload is. It is "type agnostic". The primary concern of the message bus is simply to keep track of who should get each piece of communication (pub/sub). A benefit of this model is that it will support future expansion that you don't yet have the specs for. You might add in a new message type down the road and this model will be happy to deliver it. A message bus is more likely to be distributed outside your application and perhaps even outside your machine (say distributed between a cluster of 10 servers).
A command handler model is concerned with separating the actions from the execution of a command. Traditionally (at least in the languages I use) commands were very tightly associated with UI controls and their events and the UI thread. With this old model, it was also difficult to customize or extend the range of available commands in your application (say with an extension DLL). The command handler model separates those concerns of UI and command execution. You now have the flexibility to easily add more command handlers and to execute commands without a UI event (Unit test-able). This makes for cleaner, more modular and testable code. The command handler is more likely to be part of your application internally. Any extensions to your commands collection are likely intended to affect your one application and not multiple applications.
A Message/Command Broker is concerned with connecting incompatible or differently designed independent systems. This is the use case where you want one application to interface with another and don't have the source code to one or both applications. So you create a broker which receives information from one side and provides this information on the other side taking into account any transformations necessary for these two apps to communicate. The example on MSDN is an ecommerce website which might need to talk to a payment processor, a shipping company, and an accounting system. You may not have the ability to change the source code for any of these apps (including the ecommerce system). Maybe the ecommerce system requires an IExamplePaymentGateway interface and your payment provider requires a IDifferentPaymentAPI interface. Maybe one API is implemented in XML and the other in JSON? Whatever the differences, your broker is responsible to make the connection possible.
As you can see they all involve communicating in one way or another. The lines between them can be blurry and you may even use a combination of several of these patterns to achieve your particular use case.
While I've never used NServiceBus, most of these type of libraries simply try to wrap up the abstract/academic models into more concrete language specific implementations. Sometimes this saves you time, sometimes you get stuck with a poor implementation from an unknown open source contributor. You'll need to evaluate your own use case and the suitability of the tools available in your preferred development language.