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

This post originally appeared on Extol.com (EXTOL has been acquired by Cleo).

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.

To accommodate different ways to use the data, there are several different types of subscribers.  The basic “subscriber” registers with an ESB queue to receive data.  More than one subscriber can register with an ESB queue.  This is a common, useful approach to “carbon-copy” the data to several targets.  An example of this implementation includes sending shipment information from an ERP system to a third-party logistics company, as well as, an internal data warehouse.  This subscriber only sees messages when it’s connected to a message queue.

Competing Subscribers offer a solution to implementations with the requirements that only one “node” processes a message.  When a Competing Subscriber consumes the message, the message is removed from the data queue, preventing another downstream node from processing the same data. This is common in load-balanced scenarios, ensuring that only one node processes each message.

Subscribers can also require the Provider to persist messages, in case they are disconnected at the time of message publication.  This subscriber is known as a Durable Subscriber. Once the Durable Subscriber connects to a message queue, it retrieves any waiting messages and then actively processes newly published messages.  An example of this approach could be an external business partner that has a Service-Level Agreement (SLA) for guaranteed delivery of all messages, but only connects to the ESB several times a day.