Difference between a Message Broker and an ESB

Question

Dear All, 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 Message Broker and an ESB? Now here I am trying to compare products, Websphere Broker and Mule ESB!!

Firstly , is (any version) Webshere Broker an ESB? Our IBM product guys claims it to be an ESB!(I am not surprised about that).

My limited information tells me that a Message Broker works on a HUB-SPOKE model. However the ESB works on a bus architecture. Now what on earth is that supposed to mean? I have read than if the HUB fails(unavailable I guess) then the broker completely fails. Which is not the case of an ESB(So those guys say). What I dont understand here is "What if the BUS" fails?

Now the usual stuff about an ESBs and Borkers is that , they provide routing,transformation, orchestration etc.. So if both of them provide this, then why would I choose one over the other.

Another area of conflict is regarding the TRANSFORMATION. Does ESBs facilitate it in a different way when compared to Message Brokers? I would really love some insight on this.

Now talking about HORIZONTAL scaling. Who outperforms the whom? Or are both of them equally scalable in terms of complexity(or any other factors). Ofcourse cost wise, Webshpere Broker is gonna charge you for each box(let alone each cpu). I believe , even the commercial MULE ESB doesnt do that. Leaving aside the Cost part of it, what are the implications of ESB scaling and Message Broker scaling. I happen to know you can scale up to Service Level in ESB. Is this possible in a Message Broker?

Regards, Franklin

Answer 1

Disclaimer: I am an IBM consultant and specialise in WebSphere ESB. This comment isn't left in any official capacity.

An ESB is more of an architectural pattern or concept than a product - broadly, a service-based way of engineering loose coupling. Its definition is fought over and not exactly set in stone. In general, an ESB is set of unrelated (in a technical sense) services - they expose interfaces, and they consume them from other services. Generally there isn't a hub and spoke architecture involved, although there can be.

IBM certainly markets both WebSphere Message Broker and WebSphere ESB as products that make it easy to build an ESB (along with the DataPower hardware appliance). They have different technological roots, but have some overlap in purpose. Also, that's not to say you can't build an ESB with lots of other things that aren't branded as an 'ESB product'.

That doesn't answer all your questions, but hopefully addresses the IBM part.

Answer 2

You can use a transformation broker without a service bus, and vice versa. In terms of specific products I don't think any one is purely one or the other because of the way each complements the other. Some products are stronger in the one area, other stronger in another. Perhaps a choice needs to be made based on which function best covers an individual problem.

A broker may have better built-in "lego blocks" for constructing a transformation chain than an ESB product does. A broker pressed into service as an ESB may be crushed under load and not scale well, or may lack robust journaling and tools for dealing with journals.

Some ESBs allow database updates to be rolled back and queues to be replayed into a corrected application once an egregious error in logic has been uncovered and fixed. I don't think most brokers integrate that level of transactional support. For this to work at all your "transactions" almost have to be business events (a sale, a renewal, a change of ownership, etc.) rather than something like RPCish "database updates."

Answer 3

Franklin - do you have any other example to explain as you explained taking example as food prepared by two different people can't consider the same role :))...there could be some business purpose using ESB and WMB.

Cheers Afroz