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

The ESB publish/subscribe model





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.