Difference between a Message Broker and an ESB

Question

I have gone through different questions/articles on Message Brokers and ESBs(Even on stackoverflow). Still not a clue as what is the CLEAR demarcating difference between an Mess

Answer 1

The difference between a Message Broker and an ESB (Enterprise Service Bus) is mainly the word 'bus'.

To me, a Message Broker is one (usally big) process that transforms data from one structure to another structure or modifies content.

An ESB is a message oriented middleware (MOM) plus additional services, one of which could be a Message Broker. So an ESB can include a Message Broker as one of it's components. A Bus consists of more than one processes, otherwise I wouldn't call it a 'bus'. The nature of a bus is that there are multiple components serving different tasks, each one communicating over a MOM and adhering to some form of 'common data format'. A bus would consist of: applications sending data to the MOM, database adapters, Message Brokers, MOM bridges, etc.

The separation is a bit gradual, but the biggest difference between a Message Broker architecture and a Bus is that of granularity. If your task is to integrate applications A, B, .., Z and a couple of databases, you can do this with one big Message Broker connecting each and everyone. Or with an ESB where multiple small components take over just little tasks. For example one adapter connects to A, another one to B (but they don't do transformation), then each one sends their stuff to one (or more) Message Broker, each of which should be kept as simple as possible - e.g. not having to know about the data model of 'A' or 'B'. A good ESB should have a common data definition on the bus, abstracting from the 'differentness' of individual applications.

TRANSFORMATION: an ESB doesn't help with transformation, unless it comes with a Message Broker. But each good ESB should include a Message Broker anyway. The Message Broker should be your bus's expert for transformations, but nothing else.

HORIZONTAL scaling: if you only have 3 things to connect (now and forever), it's probably not worth the effort to get a full-blown ESB. A Message Broker has the advantage of being just one big process. You can configure everything in there and have a central location for all your data mappings, filtering and routing.

But if you have 30 applications to connect, one Message Broker would probably come to grinding halt. Of course you can buy more instances, run things redundant, etc. but you should change your strategy to 'localize' jobs. Each application's adapter (could be one little Message Broker instance each) should be able to generate and/or receive an abstracted common data model (e.g XML with a shared XSD). There could also be a central Message Broker for transformation tasks, but that instance should be unaware of data model A or B. So an ESB should move the processing to the expert component instead of keeping everything in a central place.