Publish/subscribe
From Wikipedia, the free encyclopedia
Publish/Subscribe (or pub/sub) is an asynchronous 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. Subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what (if any) publishers there are. This decoupling of publishers and subscribers can allow for greater scalability and a more dynamic network topology.
Pub/sub is a sibling of the Message Queue paradigm, and is typically one part of a larger Message-Oriented Middleware solution. Some messaging systems (e.g. JMS) support both the pub/sub and Message Queue models.
Contents |
[edit] Message Filtering
In the pub/sub model, subscribers typically receive only a sub-set of the total messages published. The process of selecting messages for reception and processing is called filtering. There are two common forms of filtering: topic-based and content-based.
In a topic-based system, messages are published to "topics" or named logical channels. Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages. The publisher is responsible for defining the classes of messages to which subscribers can subscribe.
In a content-based system, messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber. The subscriber is responsible for classifying the messages.
Some systems support a hybrid of the two; publishers post messages to a topic while subscribers register content-based subscriptions to one or more topics.
[edit] Topologies
In many pub/sub systems, publishers post messages to an intermediary broker and subscribers register subscriptions with that broker, letting the broker perform the filtering. The broker normally performs a Store and forward function to route messages from publishers to subscribers.
Other pub/sub systems eliminate the message broker by distributing the routing and filtering functions among the publishers and subscribers, sometimes with the help of daemons.
[edit] Advantages
Loosely-coupled: Publishers are loosely coupled to subscribers, and needn't even know of their existence. With the topic being the focus, publishers and subscribers are allowed to remain ignorant of system topology. Each can continue to operate normally regardless of the other. In the traditional tightly-coupled client-server paradigm, the client cannot post messages to the server while the server process is not running, nor can the server receive messages unless the client is running. Many pub/sub systems decouple not only the locations of the publishers and subscribers, but also decouple them temporally. A common strategy with such pub/sub systems is to take down a publisher to allow the subscriber to work through the backlog (a form of Bandwidth throttling).
Scalable: Publish/Subscribe provides the opportunity for better scalability than traditional client-server, through parallel operation, message caching, tree-based or network-based routing, etc.
[edit] Disadvantages
For pub/sub systems that use brokers (servers), the agreement for a broker to send messages to a subscriber is in-band, and can be subject to security problems. Brokers might be fooled into sending notifications to the wrong client, amplifying denial of service requests against the client. Brokers themselves could be overloaded as they allocate resources to track created subscriptions.
Even with systems that do not rely on brokers, a subscriber might be able to receive data that it is not authorized to receive. An unauthorized publisher may be able to introduce incorrect or damaging messages into the pub/sub system. This is especially true with systems that broadcast or multicast their messages. Encryption (e.g. SSL/TLS) can be the only strong defense against unauthorized access.
[edit] Articles
- Publish/subscribe and SOA: How EDA extends SOA and why it is important Jack van Hoof
