[Bernstein09] Section 4.6. Publish-Subscribe

4.6. Publish-Subscribe
Usingqueued communication, each message has a single recipient—the processthat dequeued the message. By contrast, some applications need to senda message to multiple recipients. For example, this arises with anotification service that broadcasts an alert when an important eventoccurs, such as a major change of a stock price. If the sender knowsthe identities of all the recipients, it can broadcast the message bysending the message to each of them. However, this is inconvenient ifthere is a large number of recipients. And it may not even be feasibleif the sender doesn’t know the identities of all the recipients.
To handle the latter case, a different communication paradigm can be used instead, called publish-subscribe. In the publish-subscribeparadigm, a publisher sends a message to a broker that is responsiblefor forwarding the message to many subscribers. Typically, thepublisher tags each message by its type. Each subscriber registersinterest in certain message types. After receiving a message from apublisher, the publish-subscribe broker sends the message to allsubscribers that have registered an interest in that message’s type.
Thepublish-subscribe paradigm is like queuing in three ways. First, thesender and receiver are decoupled, in the sense that they don’tcommunicate directly with each other. Instead, they each communicatewith the message broker. In fact, if one equates the notion of messagetype with that of queue, then the similarity is even more pronounced;in effect, senders enqueue messages to a queue for the message type andreceivers dequeue them.
Second,messages can be sent or received in the context of a transaction. Inthat case, the operations to send or receive a message are undone inthe event of an abort.
Third,subscribers can use either a pull or push model. In the pull model thesubscriber can explicitly poll for new messages that satisfy itssubscription. In the push model when a message arrives a dispatcherforwards the message to all subscribers whose subscriptions includethat message.
Giventhese similarities between queuing and publish-subscribe systems, thetwo communications paradigms often are supported by a common queuemanagement implementation. This has become especially common since thedevelopment of the Java Message Service (JMS) standard, which includesa programming interface for both point-to-point messaging andpublish-subscribe. Other standard interfaces that offerpublish-subscribe capability are the CORBA-Notification service andWS-Eventing or WS-Notification for Web services.
Inthe simplest version, the message type is simply a name, sometimescalled a topic. In more advanced versions, types can be grouped into ahierarchical namespace. So a type could be a path in the namespace,such as “Equity-exchange/NY-stock-exchange/IBM” rather than simply“IBM.”
Somepublish-subscribe systems allow subscribers to identify messages usingpredicates that refer to the messages’ content. For example, one couldsubscribe to (type = “IBM”) and (price > 100) where price is a fieldin the message content.
Publish-subscribesystems usually offer the option of having a subscription be persistentor volatile. If it is persistent, then each message is delivered to allregistered recipients. If a recipient is unavailable when the messagearrives, then the message broker retains the message and resends itwhen the recipient becomes available. If the subscription is volatile,then when each message arrives, the message broker forwards it to allregistered recipients. If a recipient isn’t available, then it simplydoesn’t receive the message; the message broker does not attemptredelivery when the recipient becomes available.