Publish/Subscribe Protocol

Publish/Subscribe Protocol is a model to control the event flows (changes of data) in software using two entities: subscriber and publisher. The event is used to signal changes from publisher to subscriber(s). From here, we can conclude the publisher is the producer of events, and the subscriber(s) is the consumer of the events that it needs.

The publisher doesn’t need to have any explicit knowledge of the subscriber, plus the subscriber(s) can have its own agenda different from others. That being said, the publisher should keep track of who is subscribing to it, and call each of them in turn and notify them if an event occurred. In case where the subscriber(s) decides to unsubscribe from the publisher (it doesn’t need that information any more), it should remove that subscriber from subscribers list in order to prevent it from getting notified.

Note: Avoid having a subscriber that has to handle more than enough or all the events that they don’t need. It will decrease the coupling since it doesn’t have the knowledge# about them in order to interact with so many objects.

There are many implementations of Publish/Subscribe Protocol:

  • peer-to-peer
  • centralisation (software bus like CORBA Event Service#, an object responsible to maintain a database of listeners and distribute the messages accordingly), and
  • broadcast (regardless of registration).

We can further #decouple the model using Model-View-Controller (MVC)#.

However, there could be two extreme cases by adopting this protocol: push model and pull model. Push model happen when the publisher sends subscribers detailed information about the change without determining whether it is necessary. This might make the subscribers less reusable. Pull model is on the opposite polar where the observer ask details after the minimal notification from publisher. It is rather inefficient. These two model could be avoided if a parameter of the interests that the subscriber needed is passed during an update. That way, only needed details are passed to the observer.

Links to this page
  • The Pragmatic Programmer

    In a multithreading environment#, real-time system an event-based application#, tracing statements (printing messages as simple as “got here” or “value of x is 2” to the screen or a log file) are more helpful than a debugger (with only stack trace, the state of a program now). They should be in a regular, consistent format so one could read or parse them easily.

  • Observer Pattern

    Observer Pattern is a #Design Pattern that could be used to implement #Views utilising the Publish/Subscribe Protocol. It is rather useful at decoupling# the presentations of the data from the data itself. There are two objects in this pattern: subject and observer. Observers don’t need to know each other’s existence, but depends on the subject. When there is a change happen in subject, the subscribed observers need to be notified to synchronise the change. This either done in subject to notify all observers that it keep track of (broadcast), or making it the observer’s responsibility to trigger the update when it is needed (centralised or peer-to-peer).

  • Model-View-Controller (MVC)

    With the combination of the concept #Publish/Subscribe Protocol, we can treat model as the event, view as the subscriber to the events and controller as the publisher of those events. Since the controller has the ability to provide new data to the model, there could be the case it is, too, a publisher to the model.

  • Mediator Pattern

    Mediator Pattern could also incorporate #Observer Pattern to implement Publish/Subscribe Protocol as a communication mechanism. Colleagues, implemented as subjects, will notify Mediator, implemented as observer, in an event of interests where the Mediator object calls other colleagues according.

  • CORBA Event Service

    CORBA Event Service is a centralise implementation of #202207041109 which utilises the event channel (a common software bus shared by other objects) to allow pushing and/or pulling of event notifications.

#oop