Tag Archives: Enterprise Service Bus

The Publish/Subscribe Model: You gave the message to whom?

Enterprise Service Busses (ESBs) offer an interesting communications layer that enables an enterprise to expose data to interested parties (i.e. applications, data-feeds, etc.) with a Publish/Subscribe model.  The Pub/Sub model originated in the printed media world, utilized as a distribution model for newspapers and magazines. It has evolved with modern times into the electronic age in the form of email-subscribed newsletters, and more recently, RSS feeds such as blogs.

In the enterprise, there is a growing need to share data among systems, both internally (A2A) and externally (B2B).  However, as new demands for sharing data surface, we need a way to “bolt in” the new requestors without impacting our current implementations.

ESBs commonly implement a variant of the GoF Observer Pattern.  This exposes a Publication/Subscription model allowing information sources (publisher) to expose data (message) on a queue.  One or more interested parties (subscriber) consume the data.  The key benefit of loose coupling in a Publication/Subscription model is that the Publisher does not need to know, or care, about “who” is subscribing.  The data is published and downstream subscribers use the data as they see fit.

Continue reading

The Enterprise Service Bus, in Context

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.

Continue reading