An Enterprise service bus is a cool piece of technology designed to solve a specific problem. Basically, it’s and N to N multicast communication device. You can have a variable number of message senders and a variable number of message recipients. Decoupling the senders and receivers and decreasing the number of touch points in inter-service communication.
The downside of an enterprise service bus solution is that you need to make sure you have an ESB type problem. Like a lot of enterprise patterns such as CQRS, an ESB is great at solving it’s specific type of problem and truly horrible when it’s not applied to the right problem.
The kind of problem that an ESB is designed to address is one where you have a varying number of senders and a varying number of receivers. If each sender needs to know about all the recipients, managing the configuration gets very painful very quickly. Similarly for the receiving side.
What an ESB is not good for is when there is a single recipient of a message or a load balancing situation. If you’re trying to distribute the processing across a bunch of workers, then an ESB isn’t for you, that’s a different kind of messaging problem best solved with a message queue. If you have a process where you have a single recipient for the message, then it’s almost never a good choice for an ESB solution.
However, if you have a series of short lived processes that need to send messages to a variety of senders, then an ESB is a good solution. Decoupling the sender from the receiver means that neither party needs to be concerned about reaching the other. The ESB handles the delivery, no one needs to worry about who the other party or parties are.
Architecting a solution in an ESB environment is a little different. Because the communication is decoupled some different things to be considered. One of them is that since there isn’t a direct link, synchronous operations aren’t really a good fit.
Scott's Thoughts 