ESB: Enterprise Service Bus

There has been plenty of discussion recently about the concept of an Enterprise Service Bus (ESB). For example, here are some comments by Radovan Janecek from Systinet.

There doesn't seem to be a broad consensus of what an ESB is. The word "bus" connotes a backbone that services can use for communicating with other services, with features such as reliable point-to-point and publish-subscribe messaging. Some definitions of ESB broaden the role beyond messaging to include shared infrastructure such as monitoring, billing, and security.

The equivalent of an ESB in animals is the nervous system combined with the circulatory system. When an organ needs to communicate with another specific organ, it uses the nervous system to send a point-to-point message. When an organ needs to broadcast a message to other organs that might be interested, it releases a hormone into the bloodstream to send a multicast message.

Because reliable point-to-point and publish-subscribe are naturally occurring message modes, most SOA systems need an ESB. There are many ways to implement such an ESB, and if you believe in SOA architectures, you would expect an ESB to be implemented as a collection of services. For example, one service could provide reliable messaging, while another service could provide publish-subscribe. For reliability, shared services would be replicated. This meshes nicely with Radovan's definition of an Enterprise Service Network (ESN). I don't see any conflict between an ESB and an ESN; an ESN is just one way to implement an ESB.

Comments

[Radovan Janecek]

Graham, I very much agree with your approach: ESB as a collection of services. Though I don't think there should be a 'service providing reliable messaging', just for example.

I see two types of ESB vendors:

1) EAI players that have no 'SOA' technology. ESB is marketing survival strategy.

2) EAI players that have 'SOA' technology but their marketing departments insanely jumped into the ESB trap.

[Ronan Bradley]

There is a general tendency to dumb down what an ESB can or should do. Following on from Radovan's comment, this is much more to do with what EAI vendors have today than what customers want from an ESB.

To comment on the analogy of ESB = circulatory and nervous system: I beg to differ.

Unlike most organizations' IT, the human body was designed to work together as a single integrated whole: It has evolved by creating a completely new body with some minor changes - rather different to IT which must live with its entire evolutionary history at any one time.

If the human body was like most organizations, we might well have the combination of the heart from a dinosaur, perhaps some gills to breath with and the left leg of a neanderthal! And then one day we would wake up and discover that we now have two heads and an extra leg following a merger with the dog next door.

If this was the case, our circulatory and nervous system would have to be a lot smarter than firing messages off and pumping hormones around!

We all know that is the case with large organizations and that is why an ESB needs to be a lot smarter and in fact deliver many of the EAI capabilities - all be it in a standards based, easy-to-use/easy-to-evolve, quick to implement fashion.

[Fatos]

Thanks Graham for ths post, this was very intresting for me as i am new in this technology and i think you explained it well.

thanks again and regards

fatos