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.
An example of an ESB implementation is placing an ESB between an Order Processing system and an ERP back-end. As orders are received by Communication Adapters (FTP, File-Based or Web Services), they are published to the ESB by attaching or wrapping the order within a message. Once the message is published to the ESB, routers (content-based or static route) recognize the new message and identify target “subscribers”, such as applications, services or other ESBs, that wish to receive a copy of the message (except in the place of the Competing Subscriber pattern where the first subscriber gets the goods!).
The advantage to this approach is that the Order Processing system does not “know” who receives the orders, nor should it care. It performs its function and then hands off the data to the ESB. Examples of downstream subscribers could be the ERP back-end, a Data Warehouse aggregator and a legacy MRP package. As you can see, all three subscribers receive the data without regards to how it came to their door. As the legacy MRP system is replaced, the new MRP system is simply bolted on to the ESB. There is no impact to the Order Processing system. Additionally, new services can subscribe to the ESB to take advantage of access to the data. This is an example of how loose-coupling, by leveraging an ESB, can improve overall system reliability and resilience to change.
In the next installment, we will explore the ESB Publish and Subscribe model and the different ways that this technology can be used.