Publish-Subscribe Design Pattern
While developing embedded system, one frequently encounters a situation where many entities are interested in occurrence of a particular event. This introduces a strong coupling between the publisher and subscriber of this event change notification. Thus whenever a new entity needs the information, code for the publisher of the information also needs to be modified to accommodate the new request.
An Example
Consider the example of a system which manages terminals. Here many entities would be interested in knowing when a terminal's status changes. A few examples are:
- Call Processing module needs to know when the terminal goes out of service so that calls on the terminal can be cleared.
- Alarm processing software needs to know of terminal status change, so that alarms can be raised/cleared.
- Resource manager would be interested in terminal status change as it needs to change the resource counts when terminal status changes.
As the design progresses, more and more applications would be interested in status change. Its easy to see that this complicates the design, as terminal status handling has to be modified on each occasion.
Publish-Subscribe Pattern
The Publish-Subscribe Pattern solves the tight coupling problem. Here the coupling is removed by the publisher of information supporting a generic interface for subscribers. Entities interested in the information subscribe to the publisher by registering for the information. With this interface, the publisher code does not need to be modified every time a subscriber is introduced.
Whenever information needs to be published, the publisher invokes the Publish method to inform all the subscribers.
This pattern comes in two flavors:
- Local Publish-Subscribe Pattern: Use this pattern when publisher and all the subscribers are a part of the same task.
- Remote Publish-Subscribe Pattern: This pattern should be used when publisher and subscribers are implemented in different tasks/processors. All communication takes place via messages.
Local Publish-Subscribe Pattern
Here we develop the LocalStatusPublisher class. This class can be used as a helper class when this generic subscribe-publish interface is desired. The following important public methods are supported:
- PublishStatus: Invoke this method to inform all registered subscribers about status change.
- Register: Invoke this method to register an object for the status change notification.
- Deregister: Invoke this method to deregister an object. The object will not receive any notifications of status change after it de-registers.
Local Status Publisher
Remote Publish-Subscribe Pattern
Here we will look at the RemoteStatusPublisher class. This class supports a message based interface. Subscribers send registration request message to register for the status change. The source address of the sender is saved as a part of the registration process. De-registration request is sent to stop receiving the status change notifications.
Whenever status change is detected, PublishStatus method is invoked. This method sends the status change message to all the registered subscribers using the address that was obtained during registration.