Publish/Subscribe paradigm: Why must message classes not know about their subscribers?

Question

From Wikipedia: "Publish/subscribe (or pub/sub) is a messaging paradigm where senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers). Rather, published messages are characterized into classes, without knowledge of what (if any) subscribers there may be"

I can understand why a sender must not be programmed to send its message to a specific receiver. But why must published messages be classes that do not have knowledge of their subscribers?

It would seem that once the messaging system itself is in place, what typically changes as software evolves is the messages sent, the publishers and the receivers. Keeping the messages separate from the subscribers seems to imply that the subscription model might also change. Is this the reason? Also, does this occur in the real world?

I realize this may be a basic question, but I'm trying to understand this paradigm and your replies are very much appreciated.

Answer 1

It's just about separation of concerns, adherence to an interface, and isolation. Why do you think they would need knowledge of their subscribers?

A message is posted to a bulletin board. There are multiple bulletin boards of different topic. There may be no readers. There may be readers (subscribers) who come in every day and check the board for topics of interest. There may be 10,000 readers who read them all.

As long as the message is written in a language the readers are expected to know, why would the poster (publisher) or the messages themselves need to know anything else about the subscribers?

I think the message has knowledge of the interface/contract receivers use for messages, but that's about it.

It seems like this model also allows one-way information flow... in order to know something about your subscriber, there must be a two-way flow of information.

Answer 2

I don't think the rule is absolute by any means, and if you can find a situation where the message having knowledge of the subscriber is useful I don't think anyone will tell you you're wrong (they may tell you there is a better way, however).

Keep in mind, however, that scalability and backwards compatibility would be directly impacted by the message being aware of its subscribers.

Compatibility-wise, What happens when a new process wants to subscribe to a message? Who's responsible for letting the message know (would this default to the publisher)? And how does this new requirement preclude you from preserving past messages for future consumption, as they wouldn't be aware of future subscribers.

Scalability wise, what happens when your message system becomes popular, and everyone and their mother begin to develop different subscribers to your app (like twitter)? How do you handle each message being sent one thousand times (one for each subscription client) or sending one much larger message? This could preclude you from using other technologies, like SMS, or creating greater latency for reliable transmission technology.

It's probably stated that way to avoid headaches further down the line.