I have in the past gotten in a tizzy about message brokers and message busses. I pretty much say, busses rule and brokers drool. This stems from the fact that I view them as filling the same role, the intermediary between applications. Because of this view point, I see the broker as being a central point of failure and I see the bus as being a distributed equivalent, that overcomes much of the problems of centralization. I often dismiss the simplicity of centralization in this area from an academic snobbery vibe, which is just not the right way to go about it. So I decided to do something about it.
It was while rereading EIP for this series I realized that the authors actually classified the two patterns into two different categories (they do not fill the same role!). The bus is a channel for message sending and the broker is a message routing mechanism (well crap, I have to abandon my old assumptions). With this realization, what does that mean for my previous assumptions?
So, just how does the EIP define these two patterns?
Message Broker – a means to decouple the destination of a message from the sender and maintain central control over the flow of messages (inside cover of EIP).
Message Bus – enables separate application to work together but in a decoupled fashion such that applications can be easily added or removed without affecting others. (inside cover of EIP).
Well, hmmmm? Could it be that its possible for a software package to be both? It seems like it. Lets review. While working on MassTransit I feel that I have successfully accomplished the message bus pattern, but the broker pattern? Decouple the destination of a message from the sender and maintain central control over the flow. Well we have decoupled the sender from the receiver by following the publish / subscribe model, but the central control of flow? Well no, but do I want that? … Centralization == single point of failure. hmmmm…. “the message broker pattern only tells us to develop a single entity that performs routing. It does not prescribe how many instances of this entity we deploy in a system at deployment time.” (EIP, pg 324) So does mean that the MassTransit SubscriptionService and Client are a broker pattern built for a more distributed system? It certainly seems possible. The Subscription Service lets you control in one point where messages go (the flow). Ok, well slap my biscuits looks like I am a fan of the broker model. That’s what I get for basing my snobbery on a one time read. 😉