As its name implies, the publish-subscribe model is useful for integrating one system to many systems. Instead of directly hardwiring one system to another, the destination in this model is a topic to which receivers can subscribe; a receiver is free to subscribe as many topics as desired.
A publisher sends a message to a topic, and all subscribers to the topic receive the message. The canonical example of this model is a financial institution, where financial analysts would like to be notified in real-time of events affecting their portfolio companies.
Figure 2 illustrates such a scenario.
Figure 2 A typical publish-subscribe model.
The system administrator is responsible for specifying the list of topics to which users can subscribe, and topics can be added or deleted dynamically. Many integration brokers also allow the use of nested topics, which form a hierarchy. This allows a finer control over which messages are sent to the subscribers. As an example, assume that the message hierarchy for stocks is based on industries, which are categorized as follows:
Someone who subscribes to Retailers would also receive messages that involve Wal-Mart and Kmart because those two companies are subtopics. A topic is identified through a dot notation (similar to an Internet address) such as Retailers.Kmart.
The sequence for the publish-subscribe model is as follows:
The system administrator specifies the topics to which the subscribers can subscribe.
The subscriber registers a callback (a message handler to be invoked when a message is broadcast).
The publisher creates a message and sends it to a topic.
The integration broker delivers the message to the appropriate subscribers, thereby invoking the appropriate callback of each subscriber. Each subscriber is then free to perform its own unique processing when it receives the message.
Once all the subscribers have been notified and each subscriber has acknowledged receiving the message, the integration broker removes the message from the topic.
This model provides for durable subscriptions, which allow for clients who are often offline. A key example is wireless devices, which don't usually have the luxury of being constantly connected. The integration broker stores messages persistently and then forwards them to the wireless device when the device comes back online.