The Enterprise Service Bus
It seems like everyone’s architecture diagrams has a big “Enterprise Service Bus” drawn down the middle of it these days. It’s as if you get a prize for just including the notion of an ESB and indicating that everything is loosely coupled. The problem is that an unmanaged, misused or overused service bus can become one big Enterprise Cesspool.
Don’t get me wrong – ESBs are a great addition for many companies if used properly. If you are publishing a message for which there are many subscribers and if you can lose some messages without causing problems then by all means implement an ESB. Centralized logging of messages, trickle loading of data warehouses and even updates to prices or inventory in search nodes are all examples of ESB activities. Just ensure that your application is either resilient to or can recover from intermittent message loss.
Don’t fall into the trap of thinking that message buses are the only solution for communications. Asynchronous communication is preferable where possible, but there are many options beyond message buses. You can implement asynchronous point to point communication methods (we often differentiate these from bus architectures and call them queue architectures). You can also implement async-sync point to point methods that allow a busy application to “fire and forget” into a queue while another application works through the queue and synchronously communicates to another consumer process or to multiple data stores where necessary. And sometimes, when it absolutely positively has to be there overnight, it is best just to communicate synchronously. Be a wise craftsman/engineer and choose the right tool for the job. After all, it’s rare that a carpenter chooses to cut a board with a hammer.
Service buses can easily also become cesspools. Someone needs to ensure that the bus is built with an appropriate number of independent channels so that communications paths don’t become congested. Treat buses as you would any other piece of infrastructure and scale them horizontally with multiple channels, routing services, etc. Monitor them aggressively to include message latency, age of the oldest message, number of undelivered messages, etc.