Enterprise Service Bus
An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.
The word "bus" is a reference to the physical bus that carries bits between devices in a computer. The enterprise service bus serves an analogous function at a higher level of abstraction. In an enterprise architecture making use of an ESB, an application will communicate via the bus, which acts as a message broker between applications. The primary advantage of such an approach is that it reduces the number of point-to-point connections required to allow applications to communicate. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact to a particular application, the process of adapting a system to changes in one of its components becomes easier.
- Provides the foundation for application-to-application integration
- Automates, manages, and optimizes business processes and workflows across systems, people, and partners
- Faster and cheaper accommodation of existing systems.
- Increased flexibility; easier to change as requirements change.
- Standards-based.
- Scales from point solutions to enterprise-wide deployment (distributed bus).
- Predefined ready-for-use service types.
- More configuration rather than integration coding.
- No central rules engine, no central broker.
- Incremental changes can be applied with zero down-time; enterprise becomes "refactorable"[