SQL Notification Services Architecture

Understanding the internal architecture of SQL Notification Services will aid you in administering notification applications, as well as in diagnosing problems that may occur. This section provides an overview of the various functional components of a notification application built on SQL Notification Services and distinguishes those supplied by the platform from those implemented by the application developer.

Figure 45.2 shows the functional components of an application. There are three main running elements, represented by the three large boxes in the figure:

• A subscription management application that allows users to enter subscriptions

• A SQL Server that stores data for the notification application, and is used as the basis for the matching engine

• A Windows Service that hosts the event collection, notification generation, and notification distribution components of the application

Figure 45.2. Functional components of a notification application built on SQL Notification Services.

These three elements can run on the same computer, or on separate computers. The various functional components within the Windows Service can even be distributed onto separate computers. This allows you to scale out the pieces of the application that require the most resources.

The following sections will describe each of the functional components shown in Figure 45.2.

Subscription Management

The component at the top of Figure 45.2 deals with management of subscriptions. Typically, users (subscribers) deal with the notification application by means of a standalone subscriber and subscription management application. This application provides an interface by means of which users can enter, modify, or delete subscriptions and configure the devices to which they want their notifications sent. Often, this application takes the form of an ASP.NET Web application, though it really can be any kind of application, including regular ASP, a Windows application, or even a command-line application.

Whatever form the application takes, internally it uses APIs provided by Notification Services to manage subscriptions. These APIs consist of a set of managed classes that represent subscribers, subscriber devices, and subscriptions. The application creates objects that are instances of these classes, and sets the values of various properties on them. The application then calls a method to submit the property values to Notification Services, where they are ultimately stored in the database.

SQL Server Database

The SQL database shown in the middle of Figure 45.2 is used both as a data store, and as the basis of the matching engine. It contains tables in which subscriber information, event data, and notification data are stored. These tables are created when the application is compiled, and as the various components of the application run, they populate these tables with data. The event data and the subscription data are matched by means of SQL joins written by the application developer.

The Windows Service

The Windows Service, shown at the bottom of Figure 45.2, hosts the core components of the application. These are the components that collect events, perform matching to generate notification data, and then format and deliver that notification data. The following sections detail each of these functional components and their operations.

Event Collection

The leftmost box in the Windows Service shown in Figure 45.2 deals with the input of events into the notification application. Events enter the system by means of an event provider: an object that can read event data from a source in the outside world and insert the events into the notification application using APIs provided by Notification Services.

For example, in the flight status application discussed earlier, an event provider might read flight status information out of the existing flight tracking database used by the airline, and then insert these events into the notification application using the Notification Services APIs. For a stock alert application, the event provider would be an object that reads stock prices from the stock provider (the stock exchange, a broker service, or another financial data provider) and submits them as events. Event providers need not be just simple pass-through mechanisms; they can perform filtering or other processing on the input data before submitting it in the form of events.

Event providers are simply managed code classes that implement an interface defined by SQL Notification Services. The application developer implements the class and Notification Services instantiates it when needed. In implementing the event provider class, the developer will build in knowledge of the particulars of the event source: how to connect to it, the protocol used to interact with it, and how to parse the data read.

In the implementation, the event provider submits events via Notification Services APIs. Internally, the APIs write this data to an events table in the application database.

Notification Services ships with several built-in event providers. If these fit the needs of the application, the application developer can use them by simply specifying some configuration information, and thus does not have to write any code.

Event providers can either run within the Notification Services Windows Service, or as standalone applications. If run within the Windows Service, they are referred to as hosted event providers. Non-hosted event providers run separately from the Notification Services Windows Service, either as standalone applications or as components of other processes.

An application can have several event providers, possibly distributed across several computers. The event providers can be enabled or disabled independently from the rest of the application.

Notification Generation

Event providers enter events into the application and a subscription management application enters subscriptions into the application. A component of Notification Services called the generator does the work to match these events and subscriptions. There is always exactly one generator per application. The generator runs within the Windows Service, but does most of its real work on the SQL Server.

The generator is a periodic component: At an interval specified by the application developer, it polls the database to determine whether there are new event batches ready for processing. The duration of the polling interval is referred to as a quantum in Notification Services terminology.

If it finds batches to process, the generator executes rules written by the application developer. These rules are SQL statements that operate on the event data and either update application state or produce notifications by matching events with subscriptions. Typically, these rules statements join the events and subscription tables and apply predicates to determine which rows match. The generator inserts the result of these joins into a notifications table.

Notification Distribution

The data in the notifications table is the output of the generator. Each of the rows in the table represents a notification to be sent, but the data in the table is in its raw form. It needs to be formatted so as to be readable by the end recipient, and then delivered via a network protocol. Distributors are components of Notification Services that perform the formatting and delivery of notifications.

A distributor applies formatting and delivery instructions specified by the application developer to the notifications in the notifications table. For scale-out reasons, applications can have more than one distributor, and these distributors can run on separate computers.

Within a distributor, formatting is done by means of a content formatter: an object that receives raw notification data as input, and returns a formatted notification message as output. Content formatters, like event providers, are managed classes that implement an interface defined by Notification Services. The application developer can implement one or more content formatters to be used by the application. Alternatively, if the requirements of the application permit, the application developer may choose to use a standard content formatter provided by Notification Services.

The application's distributors read rows of data from the notifications table and pass them to the application's content formatter. They then pass the resulting formatted strings to a delivery protocol object, along with addressing information about the recipient and target device. The delivery protocol object is an implementation of some network protocol; it delivers the notification and returns status information to the distributor, indicating whether the delivery succeeded or failed. The distributor records this delivery status information in the notifications table. The distributor can reattempt those deliveries that failed, according to a schedule specified by the application developer.

Delivery protocol objects are also just managed classes that implement a Notification Services interface. Notification Services ships with some built-in delivery protocol objects that implement standard protocols, but the application developer can implement a new delivery protocol object if the built-in ones do not fit the needs of the application.