Enterprise Service Busses (ESBs) have become a popular communication mechanism in middleware infrastructures, allowing organizations to implement messaging systems that facilitate collaboration among disparate applications and software services. All communication between components takes place via messaging on a “bus”, removing direct contact and introducing a loosely-coupled architecture into the infrastructure. Messages are published to the bus and received by subscribing to the bus. To avoid all of the messages swirling around in one large pool, the concept of topics (sometimes referred to as channels or queues) provides a degree of separation.
To make messaging effective in this design, a common messaging model must define the messages both sent and received by the ESB. These models usually include specifications for the payload of the message and any control information that is passed along. Messages can be data-centric, containing a payload, or command-level where processing instructions can be carried, such as starting/stopping a service.
ESBs also make an effective core data transport for Service-Oriented Architectures (SOA), although they are not required to implement an SOA. They are, however, a key part of an Enterprise Integration strategy and leverage many of the Message Exchange Patterns (MEPs) in use today, such as Publish/Subscribe (leveraged in communication protocols), Competing Subscriber (often used in load-balancing schemes) and Idempotent Subscribers (ensuring that you only receive one copy of a message).
The strength of an ESB lies in its ability to send/receive messages, route them based on content, transform them into other formats, and/or publish them to additional channels. The ESB becomes the “hub” of your infrastructure, connecting all of your disparate systems and services, allowing them to communicate in new ways.