An enterprise service bus (ESB) is a software architecture construct which provides fundamental services for complex architectures via an event-driven and standards-based messaging engine (the bus). Developers typically implement an ESB using technologies found in a category of middleware infrastructure products, usually based on recognized standards.
An enterprise service bus (ESB) is software infrastructure that enables service-oriented architecture (SOA) by acting as an intermediary layer of middleware through which a set of reusable business services are made widely available.
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 Enterprise Service Bus provides one of the keys to helping you achieve the goals of a service oriented architecture. It provides a flexible connectivity infrastructure for integrating applications and services, enabling composite applications to be built as a loose coupling of independent services. It is at the heart of your service oriented architecture, reducing the number, size, and complexity of interfaces and connections that must be defined and maintained.
There are four primary functions provided by an enterprise service bus:
- Its first responsibility is the ROUTING of messages. Rather than the service requestor calling directly to the service provider, the requestor sends the request to the ESB, and the ESB then is responsible for making the call on the service provider.
- Secondly, it is responsible for CONVERTING transport protocols. If the service requestor called directly to the service provider, they would need to use the same transport protocol. The ESB enables the service requestor to use one transport protocol while the service provider uses another.
- Thirdly, it is responsible for TRANSFORMING message formats. By eliminating the direct call from the service requestor to the service provider the ESB is capable of modifying the message so that the interfaces used by the requestor and provider do not have to be identical.
- Lastly, the ESB is capable of HANDLING business events from disparate sources. Therefore, the same service provider responsible for performing some particular business function can be indirectly invoked from a variety of application contexts.
Resources:
- What is an ESB and what is it good for? *
- Difference between a Message Broker and an ESB *
- ESB entry in Wikipedia
- What Is an ESB, and Do You Really Need One?
- Just what is an ESB, anyway?
Commercial and Open Source ESB
***** Stack Overflow questions
