Most methods of obtaining information from a computer involve making an explicit request for that information. Requesting information might mean querying a database, browsing a Web site, or reading information from an Internet newsgroup.
Asking for information works when you know what information to ask for, you remember to ask for it at the appropriate time, and you have access to a computer or other device that can connect you to the appropriate information source. But there are some important cases in everyday life where explicitly asking for information is inconvenient or impossible .
Imagine that you have to meet someone arriving at the airport. Knowing that flights sometimes arrive earlier or later than scheduled, you might call the airline or check its Web site for an update on the flight's arrival time. But if you forget to check with the airline, or don't have access to a phone or computer at the time you need to check, you won't get the latest information about the flight. Even if you are able to get the information, the flight's arrival time might change after your initial check.
It would be more convenient if the airline were to notify you, on whatever device you might be carrying (a mobile phone, pager, or PDA, for example) if the flight arrival time changed. However, doing this manually would be an expensive and impractical proposition for the airline.
What's needed is a notification application: software that allows users to specify the kinds of information that interest them (in this case, the arrival times of particular flights) and sends that information to the users when it becomes available. Such software is simple in concept, but can prove difficult to build from scratch. Making it scale to the expected number of users (often millions) and the volume of incoming data (often large) can be a challenge. Implementing support for multiple target devices and languages, as well as other application features, involves serious development effort.
SQL Notification Services eases the task of building notification applications by providing a platform from which to start. Applications built on this platform can be developed much more quickly than those built from scratch, tend to offer richer features, and scale better. Typical applications built on Notification Services can be prototyped in a single day, and often can be completely up and running in a matter of weeks.
The platform supports a wide variety of notification application scenarios. In addition to the flight status application discussed earlier, others that have been built on this platform include applications that send alerts to customers when certain stock symbols in their portfolios reach target values, applications that alert users when there are traffic problems on roads and highways they use in their commutes, and applications that provide immediate sports score updates for games and teams that users have subscribed for.
The two main offerings in SQL Notification Services are
To build an application, you write a little application-specific code. This code is then hosted and executed within the Notification Services framework.
To help you begin understanding the SQL Notification Services platform, let's examine the common elements of a notification application.
Figure 45.1 shows a high-level view of a notification application. On the left side, the inputs to the application are events: things that happen in the outside world that might be of interest to a particular set of users. In the case of the airline flight status example, the events would be new flight status information (changes to arrival or departure times, gate changes, or cancellations ). The top of the figure shows the other input: subscriptions. Subscriptions are users' requests for notifications (for example, "send me a notification when the status of flight XYZ changes," or "alert me when the value of Microsoft stock goes above $100").
Figure 45.1. The high-level view of a notification application.
The box in the middle is the core of the notification application. It performs matching between the incoming events and the subscriptions that have been entered to determine which users should receive notifications and what the content of those notifications should be. The output of the application, on the right-hand side of the figure, is a set of notifications that go to the subscribers.
Applications built on SQL Notification Services can use APIs and components provided by the platform to enter events and subscriptions into the system. The platform provides the matching component, which uses SQL Server as the matching engine and applies application-specific logic to determine whether a match occurs. The application can deliver the resulting notifications via either a delivery mechanism provided by the platform, or one the application developer implements.
The core components of the application run within a Windows Service provided by SQL Notification Services. They can all run on the same computer or on separate computers in order to scale out. The platform provides a set of tools for deploying, managing, and monitoring notification applications.