Publish/subscribe

From Wikipedia, the free encyclopedia

Publish/Subscribe (or pub/sub) is an asynchronous messaging paradigm that allows for better scalability and a more dynamic network topology. Publish/Subscribe is a sibling of the Message Queue paradigm, and is typically one part of a larger Message-Oriented Middleware solution. JMS, for example, supports both the Publish/Subscribe and Message Queue models.

In a Publish/Subscribe system, publishers post messages to an intermediary broker and subscribers register subscriptions with that broker. In a topic-based system, messages are published to "topics" or named logical channels which are hosted by a broker. 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. In a content-based system, messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by one or more of the subscriber's subscriptions. In a hybrid system, publishers post messages to a topic while subscribers register content-based subscriptions to one or more topics. In content-based and hybrid publish/subscribe systems, subscribers will normally receive a subset of the messages published to the broker or topic(s) to which they subscribe.

Contents

[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. A common strategy with pub/sub is to take down a publisher to allow the subscriber to work through the backlog. This is called Bandwidth throttling.

Scalable: Publish/Subscribe provides the opportunity for better scalability than traditional client-server, through parallel operation, message caching, tree-based routing, etc.

[edit] Disadvantages

Messages are typically broadcast or multicast over a network, allowing for a more dynamic network topology. However as the volume of messages increase, this can result in overloading of the network without appropriate management or pruning strategies. This may be mitigated by the fact that hardware typically enjoys better economies of scale than software.

[edit] Articles

[edit] See also

In other languages