All About Pubsub

April 17, 2006
by Gaston Dombiak and Matt Tucker

Publish-subscribe (pubsub) is a powerful protocol extension to XMPP. It's like RSS for instant messaging: users subscribe to an item and get notifications when it's updated. The general notification pattern that underlies the protocol can be found throughout the web. A couple of examples:

In this article, we'll cover the pubsub protocol in detail then discuss possible ways it can be applied.

Protocol Details

Collection and Root Nodes

The pubsub specification is defined by XEP-0060 and is fully implemented in Openfire (formerly Wildfire) 2.6 and later. The primary objects in the pubsub service are called "nodes", which users subscribe and publish to. Nodes are hierarchical (tree structure) and come in two types:

So, when a user subscribes to a node, that node is either:

The diagram at right shows both collection and leaf nodes. There is always a root collection node. In this case, we have child collection nodes "music" and "movies". The music node contains the bands "cure" and "depeche mode".

Access and Publisher Models

Pubsub provides a rich permissions framework. Nodes can have different access and publishers models. An access model defines who is allowed to subscribe and retrieve items while a publisher model defines who is allowed to publish items to the node.

Access models options are:

Publisher model options are:

Subscribing to Nodes

When a user subscribes to a node, they specify the subscription's configuration. Configuration information can include an expiration date, keywords that will be used to filter notifications, or preferences on when notifications should be delivered. Using the example pubsub model above, a user could subscribe to all events for "depeche mode" for one month, with a keyword filter of "shows".

Users may subscribe multiple times to the same node. Each node subscription may have different configuration information such as specific keywords for filtering and notification preferences. When subscribed multiple times, then the pubsub service will send a single notification to the user if several subscriptions were affected by the same published item. This optimization avoids overwhelming subscribers with many notifications for the same published item.

Once a user has requested a subscription to a node, the new subscription is subject to the access model mentioned above. If the node is using the "authorize" permission model, then node owners will receive a message asking to approve the new subscription request. Node owners can also retrieve the full list of pending subscriptions at any time. Until the subscription is approved, users will not get notifications from the node. Once approval is given, the subscription becomes "active" and the user will receive the most recently published item as well as all future published items.

Owner and Subscriber

The diagram above shows the previous pubsub service example, but with an owner and subscriber. The user Joe owns all the music nodes. Sally has a subscription to Depeche Mode, and is waiting for her subscription to the movie node to be approved.

Publishing Events

Publishing

Each time an event is published, it can contain zero, one or many items. Each item can optionally contain a payload (data). Continuing our example, Joe wants to publish the upcoming concert schedule for Depeche Mode. Each performance might be represented as an individual item, with details about the venue included as the payload of each item.

Subscribers also have the ability to query the service for the list of published items at any time. In other words, pubsub supports both push and pull for event notification.


Conclusion

We've covered the basics of the pubsub protocol and how it can be used as an event publishing and notification service. But pubsub isn't just about event notification; the framework is powerful enough to support a number of interesting collaboration use cases such as:

Have your own ideas about how pubsub can be used? We're looking forward to seeing them!