The Publish-Subscribe Phenomenon

Today, most information is accessed via the request-response model illustrated in Figure 1.1: you make a request to a known source, which responds with the information you're looking for. Browsing a website, reading an Internet newsgroup post, or querying customer records in a line-of-business application are all examples of request-response exchanges.

Figure 1.1. The request-response model of information exchange.

The request-response model places the burden on you to request the information you need. Although this is not unreasonable in many circumstances, it is inconvenient when the availability of information is hard to predict. Consider, for example, a website that sells concert tickets. To be sure you don't miss a show by your favorite band when it comes to town, you have to check the website frequently to look at the latest listings. If you forget, or are unable, to check regularly, you could easily miss a show.

An alternative to request-response is the publish-subscribe model, shown in Figure 1.2. In this model, sometimes called the pub-sub model for short, you subscribe for the information you want to receive; whenever that information becomes available, the information source publishes it to you. When you subscribe, the information source maintains a record of what information you want to receive. In pub-sub terminology, this record is called a subscription. A subscription is like a one-time request that may be fulfilled many times in the future.

Figure 1.2. The publish-subscribe model.

Returning to the previous example, the concert ticket website could be extended to support pub-sub, in addition to request-response. The pub-sub component could allow users to subscribe for notices about concerts by their favorite artists. When new concerts are scheduled, it would compare them against the subscriptions and send notification messages to the interested subscribers.

In addition to relieving the burden of requesting information, pub-sub systems can also offer convenience by delivering information over a variety of networks to many different devices. For example, concert notices could be delivered via text-messaging to a subscriber's cell phone. This allows the subscriber to receive the information, even when away from a computer with an Internet connection.

If you're cringing at the thought of information flowing directly to you from publishers, it's because you're thinking of a four-letter word: spam. Whereas spam is unsolicited information, most of which is uninteresting, the information sent by pub-sub systems is usually what the subscribers want to receive because they have knowingly subscribed for it. The goal of pub-sub systems is to provide information that is personalized and timely and reaches users on the devices of their choice.

Pub-sub systems are becoming popular in many industries:

• Airlines use pub-sub systems to notify their customers of flight delays, cancellations, and gate changes.

• Stockbrokers use pub-sub systems to notify their clients of significant movement in the stock market.

• Employment agencies use pub-sub systems to connect employers with potential candidates.

• Merchants use pub-sub systems to attract customers back when new products become available.

• Corporations use pub-sub systems to keep employees informed about business activity or operational events.

When it was first introduced, pub-sub functionality was seen as a frill feature: a gimmick tacked onto a few pioneering applications. Now, with the increasing demand for timely, accurate information and more ways to reach people than ever before, pub-sub systems are delivering real business value. This book is about building pub-sub systems with Microsoft SQL Server 2005 Notification Services.

Product Name Clarification

"Microsoft SQL Server 2005" is the full name of Microsoft's relational database product, which includes components such as Notification Services. For brevity, I will drop "Microsoft" from the name in subsequent usage and just refer to the product as "SQL Server 2005." I'll refer to the Notification Services component as "SQL Server 2005 Notification Services" when I need to clearly distinguish the 2005 version from earlier releases; otherwise, I'll just use "SQL Server Notification Services" (abbreviated to "SQL-NS").