A question I often get is “what is an ESB and why do I need one”? This question is motivated by a number of concerns; non-technical people have heard the term but don’t understand the concept, semi-technical people are trying to figure out conflicting vendor definitions, and technical people are confused by the debate between different service enablement approachs – RESTful versus ws-* versus middleware-supported hybrids.
The Elevator Pitch
A service bus provides a uniform and consistent platform to allow service providers and service consumers to interoperate. An ESB provides benefits such as:
- standardization
- loose coupling
- resilience and high availability
- monitoring and intermediation
Hardware
I’m not sure of the provenance of the word “bus” as it is applied in the technical domain (I’m sure there is some interesting etymology there) but you can confidently trace it back to the concept of a computer hardware bus. The idea of a hardware bus (or backplane) is that hardware components – such as sound-cards, video cards, floating point accelerators, tape-drives, barcode scanners etc – can all slot into and interoperate through a shared infrastructure. By supporting a standard hardware interface and a standard software protocol, the hardware bus abstracts the details of each individual hardware component. The key features of the harwdare bus are:
- standardized hardware connectivity to the backplane
- standardized software protocol between each component and the backplane
- hardware components can operate independently without having to know details about each other
- a single infrastructure replaces multiple point-to-point connections between components (i.e. does away with a lot of ad hoc soldering).
Software
Networked systems arrived in the seventies and grew out of control in the eighties. Early network infrastructures such as Unix sockets were hard-wired point-to-point affairs with little or no abstraction of the the two programs that were working together.
The idea of a software bus is that software components can work together – yet independently – via a standardized message passing mechanism that would abstract away the need to create individual network connections between components. The software bus would take care of routing messages to the required location and also take care of all that hard stuff like quality-of-service, reliability and scalability. This is equivalent to standardizing the “hardware connectivity” in the hardware bus. TIBCO’s predecessor – Teknekron – articulated the concept of the software bus in the early nineties
The Service Bus
So the hardware bus standardizes hardware connectivity and the software bus standardizes software connectivity. The Service Bus has refined the concept of the software bus by taking a more service-oriented approach and adding support for the XML stack underlying web services and transport connectivity (e.g. bridging HTTP to JMS).
So why do you need an ESB? More on that anon…
5 comments ↓
I enjoy reading your posts to gain insight on how to better integrate with SOA.
I recently attended a ZapThink Practical SOA conference, and found it to be particularly valuable to me as I deepen my SOA knowledge and expertise. Given that it’s still relatively unknown, I thought your readers could benefit from learning about the series of events. They really try to take the focus off the hype and vendor product-pushing, and put it instead on the “brass tacks” of making SOA work.
The events are held all over the world, and focused on a number of industry and market sectors.
In addition, ZapThink’s offered a $50 discount if any of your readers register with the code GAFPSOA1.
I hope you consider it when you’re composing your next post, even just a mention. Feel free to visit http://www.zapthink.com/eventreg.html (or mention the link to your readers). I’m spreading the news now about it because I am hoping they can get more people there!
— Danielle (NOT affiliated with ZapThink!)
[…] my last post on this topic I talked about the concept of an ESB. Here I talk about why you would want […]
[…] views on this are a product of my past experience with MOM-based distributed computing. My earlier description of an ESB is based on a MOM approach and probably differs from the common perception of a “black […]
[…] proliferation, you’re simply pushing the mappings into a central logical component which – depending on its architecture – may be a single point of failure. So what are the […]
dwedqd
Leave a Comment