Introducing SQL Server Notification Services

Microsoft® SQL Server™ Notification Services is a platform for developing and deploying applications that

generate and send notifications to users. Notifications are personalized, timely messages that can be sent

to a wide variety of devices.

Notifications reflect the preferences of the subscriber. The subscriber enters a subscription to express an

interest in information. For example, "notify me when the stock price of ADCP reaches $70.00," or "notify

me when the strategy document my team is writing is updated."

A notification can be generated and sent to the user as soon as a triggering event occurs. Or, a notification

can be generated and sent on a predetermined schedule specified by the user. The user's subscription

specifies when the notification should be generated and sent to the user.

Notifications can be sent to a wide variety of devices. For example, a notification can be sent to a user's

cellular phone, personal digital assistant (PDA), Microsoft Windows Messenger, or e-mail account. Because

these devices often accompany the user, notifications are ideal for sending high-priority information.

Notification applications are valuable for many reasons, such as the following:

• Notification applications enable you to send critical information to customers, partners, and

employees. The notifications can contain links that enable the recipient to browse to a Web site to

retrieve more information or to acknowledge receipt of the information.

• Notification applications allow you to forge more valuable and longer lasting relationships with your

customers by providing more tailored and timely services to them.

• Notification applications allow you to increase revenue by making it easier for customers to initiate

business transactions with you.

• Notification applications allow you to make you employees more effective by providing them with the

information they need, whenever and wherever they need it.

• Notification applications allow you to empower mobile users over a wide variety of devices.

Notification Services makes it possible to build and deploy a notification application quickly, and to scale

the application to support millions of users. Notification Services consists of:

• A simple yet powerful Notification Services programming framework that enables you to quickly

create and deploy notification applications. The programming framework is based on XML and

Transact-SQL.

• A reliable, high-performance, scalable engine that runs notification applications. The engine is built on

the Microsoft .NET Framework and Microsoft SQL Server 2000.

Business Scenario:

Notification Services can be used for a wide variety of applications. The following scenarios provide

examples of how you can use notification applications.

Consumer Applications

You can use Notification Services to send notifications to customers:

• A brokerage firm can send stock and fund prices based on customer-defined criteria. The notification

can contain a link that enables the customer to buy or sell shares.

• A financial institution can send bank account balances and overdraft notifications.

• An airline can send information about flight arrivals and delayed departures.

• A real estate agent can send listings that match a client's criteria for a new home.

Line of Business Applications

You can use Notification Services to monitor business data:

• A customer requires immediate attention, as reported by your customer relations management (CRM)

system. The text of the customer request is sent to the account manager.

Operational Applications

You can use Notification Services to send notifications about company operations:

• When a machine on an assembly line needs attention, the assembly line manager receives a

notification about which machine is down and what the error is.

• When a production server's event log receives a critical error, the on-call support technician receives a

notification that contains the error message.

Business Intelligence Applications

You can use Notification Services to track critical company data:

• A database maintains the current inventory of all products. When the inventory of network cards in

the South East region goes below 50, an application receives a notification. That notification tells the

application to send an order for more network cards.

Employee Communication

You can use Notification Services to ensure employees are informed about their projects:

• You and a coworker are creating a critical proposal. When the proposal is updated, you receive a

notification.
• You are working on a new product and need to keep informed of product-related research. When a

new report is available from the corporate library, you receive an e-mail that contains a link to the

report.

What is Notification Service?

Notification Services is a programming framework for creating applications that generate and send

notifications, as well as a platform for hosting those applications. Using the programming framework, you

can quickly create applications to generate and send notifications to subscribers. After creating the

application, you can deploy the application on the Notification Services platform.

What does Notification Services Do?

What Does Notification Services Do?
A notification application generates and sends messages to users who have subscribed to the application.

To understand notification applications, it is important to define key terms:

• A subscriber is a person or application that receives notifications.

• A subscription is an expressed request for specific information, such as a stock price or the scores of

a sports team, and the destination for notifications.

• An event is a piece of information that subscribers are interested in. A stock price at a specific time is

an event, as is a sports score, or a product delivery message. Almost any real-world occurrence can

be expressed as a Notification Services event.

• A notification is a message that contains information related to a subscription. A notification might

contain a message about a new high value for a specific stock or the final score for a game.

The following illustration shows the basic operation of a Notification Services application.

The application produces notifications as follows:

1. Subscribers create subscriptions related to the application.

2. The application collects events.

3. Notification Services, using Transact-SQL queries, matches subscriptions to events.

4. When an event and subscription match, Notification Services generates a notification.

5. Notification Services then formats the notification and sends it to a delivery service.
A good example of a notification application is a stock application. A subscriber could create a subscription

to be notified about stock ADCP if the stock price goes above 70, and to receive the notification on a cell

phone. The application collects stock data from a stock ticker. Each time a batch of stock prices arrives,

Notification Services compares subscriptions to the current set of events. If stock ADCP goes above 70,

Notification Services creates a notification, formats it, and sends it to a delivery service that forwards the

notification to the subscriber's cell phone.

How does Notification Services work?

How Does Notification Services Work?
A Notification Services application collects events and subscriptions, generates notifications, and then

distributes the notifications to external delivery services, such as a Simple Mail Transfer Protocol (SMTP)

server. Notification Services accomplishes these tasks as follows:

1. Notification Services stores subscriber and subscription data in SQL Server databases. Using the
subscription management objects, part of the Notification Services API, you can create a custom
subscription management application to manage subscriber and subscription data.

2. Using event providers, Notification Services collects event data and stores the event data in the
application's database. For example, the file system watcher event provider monitors a directory for
XML event data. Using this event provider, you can drop XML event files in the directory, and the
event provider reads the XML events and submits them to the application database.

Event providers can be run by the event provider host component, or can run independently of

Notification Services. For more information, see Event Collection Architecture.

3. The generator matches subscriptions and events and generates notifications. The generator runs on
a regular interval defined for the application, ensuring that subscriptions are evaluated on a regular
basis. The application developer writes Transact-SQL queries that determine how subscriptions are
evaluated and what information goes into the notifications.

4. The distributor formats notifications and sends them to subscribers using one or more delivery
services. The application developer specifies the transformation from raw data to a formatted
notification using a content formatter such as XSLT.

The following illustration shows how Notification Services implements this architecture.
The Notification Services platform uses the NS$instance_name service to run notification applications. This

service, the primary component of the Notification Services engine, runs the three internal functions: the

event provider, the generator, and the distributor.

Deployment Architecture

A Notification Services system consists of Notification Services, notification applications, databases, and

subscription management applications. When you deploy applications, you configure where these items

are located and how they operate.

System Architecture
When you deploy a Notification Services application, you must configure and support more than

Notification Services. You must also consider the data storage system, the subscription collection and

management system, and the delivery systems that are involved.

The SQL Server database engine provides storage for instance and application data. Because the

databases are critical to notification applications, the configuration of the database system is a key to

application performance. For information about configuring the database engine, see Database

Considerations and Defining the Instance Database.

The system where subscription management applications run, such as Internet Information Services (IIS),

is also part of the notification application. For information about configuring the subscription management

system, see Database Considerations.

The associated delivery systems, such as Simple Mail Transfer Protocol (SMTP) servers, receive

notifications from Notification Services and send the notifications to subscribers. For information about

configuring delivery options, see Defining Delivery Channels.

A high-level view of the relationships among these components is shown in the following illustration.

Instances and Versioning

Instances and versions are two important factors when deploying a Notification Services system.

Depending on application requirements and optimal configurations, you might run multiple instances and

multiple versions on a single system, or you might deploy an instance across multiple servers.

Instances

Notification Services is based on instances. An instance is a single, named configuration of Notification

Services that hosts a set of applications. The applications hosted by an instance use the same

configuration and can be administered as a group. Instances also provide the following benefits:

• Each instance has its own registry entries and service, allowing one instance to run separately from

other instances.

• All applications hosted by an instance share the same set of subscriber data. (This can influence

which applications you want to group under a single instance.)

• Instances can be scaled across multiple servers, providing flexible configuration and allowing higher

data throughput.

When an administrator deploys Notification Services, a configuration file specifies the name of the instance

plus its database system, database settings, applications, protocols, and delivery channels. The

administrator then creates the instance using the NSControl administration utility.

Instance deployment scenarios

An instance of Notification Services can be deployed on a single server or on multiple servers. A single-

server deployment hosts all processes — event provider host, generator, and distributor — on one server,

as shown in the following illustration.

In the single-server scenario, the event provider host, generator, and distributor processes are all hosted

by a single server. The event provider collects data, the generator processes subscriptions, and the

distributor formats notifications and distributes them to the delivery services.

The administrator configures this system by creating the instance and registering the instance on that

server.

A variation of this model uses a remote database server, such as the one shown in the following

illustration.
When an instance must be scaled out to support larger applications, the event provider host, generator,

and distributor processes can be located on multiple servers. The following illustration shows one sample

scale-out configuration.

This system uses three servers to host the Notification Services instance. Server NS1 hosts the event

provider and generator processes, while servers NS2 and NS3 host the distributor process, which formats

the notifications and distributes them to the delivery services.

The administrator configures this system by creating the instance, registering the instance on each server,

and then enabling only the components (event provider host, generator, or distributor) that run on that

server.

Version Support

You can install multiple versions of Notification Services on a single system. This arrangement allows

multiple instances to each run a different version of Notification Services if required. It also allows a single

instance to be easily upgraded or downgraded.

The following illustration shows two instances running different versions of Notification Services on one

server.
Instance NS$Inst1 is running version 2.0, and instance NS$Inst2 is running version 2.1. Both are using

the same database system and the same set of delivery services.

Application Deployment

Notification Services applications are deployed using instances. Deploying an application requires you to

have all the files that support the instance, such as the application definition file (ADF) and any custom

objects. You must also specify application information in the instance configuration file. When you create

the instance, the hosted applications are deployed with the instance.

Deployment Tasks

An administrator creates an instance by first creating a configuration file and then using a command

prompt utility called NSControl to create and register the instance. The configuration file contains the

following information:

• Instance settings, such as the instance name and the database server name

• Instance database properties that configure files and filegroups

• A list of applications hosted by the instance

• Protocols supported by the instance

• Delivery channel instances for delivering formatted notifications to delivery services

Sample Deployment

The following illustration shows a set of applications deployed on two instances of Notification Services.
In this configuration, the Stock and Weather instances are on a Notification Services server and all

databases are on a database server. The applications are configured as follows:

• The Funds and Index applications are hosted by the Stock instance. Both applications use the

configuration data in the StockNSMain instance database. The Funds application database is

StockFunds, and the Index application database is StockIndex.

• The Europe application is hosted by the Weather instance. The instance database is

WeatherNSMain, and the application database is WeatherEurope.

Deploying the applications in this way allows the Funds and Index applications to share subscriber data

and delivery configuration with each other, but allows the Weather application to have its own set of

subscribers and its own delivery configuration. The two instances also can use different versions of

Notification Services.

Administration

The system administrator is responsible for deploying Notification Services applications. Ensuring that

applications operate optimally requires careful planning and installation, configuration, management, and

monitoring.

Planning and installation is the process of defining what infrastructure is necessary for applications,

planning the system architecture, and then installing system components on each server. For more

information, see Installing Notification Services.

Configuration is the process of creating Notification Services instances. Configuration requires version

management and careful planning so that system maintenance and upgrades cause minimal service

interruptions. Configuration typically consists of the following tasks:

• Creating a configuration file.

• Using the NSControl Create command to create the instance and NSControl Register to register it.

• Loading subscription data or deploying a subscription application.

• Enabling the instance of Notification Services.

• Starting the NS$instance_name service or services that run the instance.

For more information, see Configuring and Deploying Instances.

Administration is similar to the administration of SQL Server databases. The following list contains typical

management tasks:

• Data backup. The data maintained by the notification application is critical and needs regular

backup. SQL Server supports a number of backup/restore facilities and tools, which you can configure

using SQL Server Enterprise Manager.

• Data vacuuming. Because notification applications collect event data and generate notification data,

this data accumulates in the database and must be periodically removed. This process, which is called

"vacuuming," is configured per application in the application definition file (ADF).

• Reacting to problems. Infrequently, an application might exhibit a problem related to a bad event

feed, a subscriber that is not valid, or a failing delivery channel. To react to these situations, the

Notification Services platform provides control commands to disable specific components of the

system or specific subscribers. Once the problems have been identified and solved, the components

or subscribers can be enabled again.

• Instance updates. Infrequently, notification applications must be updated to reflect new

functionality created by the application developer. Notification Services provides NSControl Update

to update a deployed instance with new application logic, without losing the existing subscription

data.

Monitoring is extremely important for proper system operation. When an application is in production, the

system administrator must monitor the application to ensure that Notification Services is receiving events

and also generating and distributing notifications. Additionally, it is very important to make sure the

delivery service is delivering the notifications.

The following objects are available to assist with monitoring:

• Performance counters
• Status and historical reports

• Event log messages

Notification Services Architecture

The Notification Services platform provides an interface for collecting subscriber and subscription data,

and contains components that collect events and generate, format, and distribute notifications. In addition

to the built-in components, Notification Services enables you to create custom components for collecting

events and formatting notifications.

This section provides information about what these components are and how they work.

Subscription Management Architecture

To send notifications, a Notification Services application must have information about subscribers, the

information that the subscribers are interested in, and information about where to send the information.

Subscription management is the process of managing this subscriber, subscription, and subscriber device

data.

Subscription management is handled by a custom subscription management application written by an

application developer. This application, which can be a Web application or standard Microsoft Windows

application, writes the subscriber, subscription, and subscriber device data to the proper databases. The

developer uses subscription management objects supplied with Notification Services to simplify the

application development process.

The following illustration shows how the subscription management objects are used by a subscription

management application to communicate with Notification Services.

Notification Services stores the subscriber and subscriber device data in a central Notification Services

database and it stores subscription data in application-specific databases. This storage method allows

applications to share the global subscriber data while separately storing subscriptions for each application.

When a Notification Services application is running, the application uses the subscription data to generate

notifications and then uses the subscriber data to format and distribute the notification. Subscription and

subscriber data is key to Notification Services operation.

Event Collection Architecture

Event Collection Architecture
Event collection is the process of obtaining event data from one or more sources such as XML files,

applications, or databases, and making this information available to a notification application. In

Notification Services, event collection is the job of event providers.

Each application uses one or more event providers for gathering events. Each event provider submits data

to the application using one of the four event APIs: a managed API, a COM API that uses the managed

API, an XML API, and a SQL Server API. A high-level view of how these providers function is shown in the

following illustration.

• The managed API uses the Event and EventCollector objects to submit single events. Using the

names of the fields in an event table, an application submits an Event object to the event collector,

which then writes the data to the event table.

The COM API uses COM interop to expose the event classes as COM interfaces.

• The XML API provides a way to bulk-load XML data. The XML event provider collects an XML

document or stream from an event source and submits the data to the XMLLoader, which then

writes the events to the event table.

• The SQL Server API uses stored procedures to load event data from database objects. Two typical

ways of using the SQL Server event provider are to invoke the provider using a stored procedure and

to run a query according to a schedule. The event provider receives a result set and writes it to the

event table using the API stored procedures.

Standard and Custom Event Providers

Application developers can write their own custom event providers using any of the APIs listed above, or

they can use one of the standard event providers supplied with Notification Services, such as the

Scheduled SQL or file system watcher event providers.

Custom event providers allow the application developer to provide functionality not available from one of

the standard event providers. For example, the developer might want to collect data from a comma-

delimited file from a stock ticker. Using the Notification Services API, the developer can create an event

provider with this functionality. For more information about custom event providers, see Developing a

Custom Event Provider.

Hosted and Independent Event Providers

An event provider is either hosted or independent.

Hosted event providers run within Notification Services. Hosted event providers can either run

continuously or be invoked according to a schedule defined in the application definition file (ADF). These

event providers are run by a Notification Services component called the event provider host. The event

provider host runs using the same schedule as the generator component; the schedule is defined in the

ADF.

Independent event providers run as external applications and submit events on their own schedule. For

example, an event provider hosted by Internet Information Services (IIS) that exposes a Web method for

submitting events is an independent event provider. An event provider that is hosted inside a process you

write is also an independent event provider.

Batching of Events

Event providers write events in batches. Writing events in batches allows the generator to more efficiently

process event data by comparing subscriptions with multiple (maybe thousands) of events at one time.

This batch-oriented processing improves application performance.

When the provider commits the event batch, the generator processes the batch. For more information

about batching, see Batching in the Notification Services System.

Subscription Processing Architecture

Subscription Processing Architecture
After events are collected in an event table, subscriptions can be processed. Evaluating subscriptions

against events is the job of the generator.

To generate notifications, the application developer creates one or more rules for the application. These

rules are written as Transact-SQL queries that specify how events and subscriptions relate, as well as any

other conditions that must be met to generate a notification.

In a simple application, when the generator fires a rule, the application evaluates all available

subscriptions against the current batch of events. When a single event matches a single subscription, the
notification generator creates a notification. This notification contains data about the event; it also

references data about the subscriber, the subscriber device, and other information required for

distribution.

The notification is not actually sent at the instant it is created. Instead, the generator writes the

notification to an internal notification table. When a batch of notifications is ready, the notifications are

formatted and distributed by the distributor.

Notification generation can be more complex than immediately matching an event to a subscription.

Notifications can be generated according to a subscription-defined schedule and can use historical data.

If an application supports scheduled subscriptions, when the generator processes the scheduled

subscriptions, it sees only subscriptions that are due for evaluation. For example, if the generator runs

every 15 minutes, at 8:00 A.M. the generator evaluates all subscriptions that are scheduled between 7:45

A.M. and 8:00 A.M.

If an application uses historical data, the application can store data in a supplemental table called a

chronicle. Applying rules written for the application, the application uses data in these tables to store

events or generate notifications.

Rule Types
The operation of the generator is controlled by the Transact-SQL rules defined for the application. You can

create the following types of rules:

• Event chronicle rules store or update the history of events in chronicle tables defined by the

application developer. Each time the generator runs, it fires this type of rule first.

• Subscription event rules generate notifications for event-triggered subscriptions. This type of rule

runs after the event chronicle rule if an associated batch of events is available. This type of rule can

also manage chronicle tables.

• Subscription scheduled rules generate notifications for scheduled subscriptions. This type of rule

runs after the event chronicle rule for any related subscriptions that are due to be processed. This

type of rule can also manage chronicle tables.

Quanta

The generator runs according to a schedule defined by the quantum time period in the application

definition file (ADF). The quantum determines how often the generator wakes up and fires rules. The

quantum period can be as short as a few seconds or as long as you want it to be. A short quantum period

causes the generator to run more frequently and consume more system resources. A long quantum

interval causes a longer delay between the arrival of events and the generation of notifications.

Notification Formatting and Delivery Architecture

The formatting and distribution of notifications is the job of the distributor. After the generator creates a

batch of notifications, the distributor reads the subscriber data in each notification to determine what

formatting is required. The distributor then formats the notification and sends it using a delivery channel

to a delivery service, such as a Simple Mail Transfer Protocol (SMTP) server.

Message Formatting

Part of creating an application is defining how raw notification data is transformed into readable messages.

Using a formatting method such as XSLT, the application developer creates a content formatter for every

combination of device and locale. For example, an application that supports the English and French locales

and Systems Management Server (SMS) and SMTP devices requires four separate content formatters.
The distributor reads each notification to obtain the subscriber delivery device and locale. The distributor

then matches the combination of device and locale to a specific content formatter to generate the

formatted message.

The formatted message can contain a combination of the raw notification data, data that is computed at

formatting time, and text specified by the content formatter. These options allow for professional and

user-friendly notification text and the inclusion of Web links.

Delivery Channels

Notification Services itself does not handle the final delivery of notifications. Instead, Notification Services

uses delivery channels, which are like pipes to delivery services such as SMTP servers. Notification

Services sends the notifications to one or more delivery channels, which package the notifications into a

protocol packet and then send them to the delivery services. The delivery services handle the final

delivery on their own.

Notification Services includes the following common protocols, which support a standard set of delivery

channels for notification applications. Multiple delivery channels can be configured for each of these

protocols:

• The SMTP protocol for sending notifications to Microsoft Exchange Server or other SMTP servers.

• The extensible HTTP protocol, which can be used for SOAP, SMS, .NET Alerts, and other HTTP-related

protocols.

• The file protocol for sending notifications to operating system files; used primarily for debugging

applications.

The application developer can define additional protocols. For more information about standard and

custom protocols, see Standard Delivery Protocols and Developing a Custom Delivery Protocol.

To support delivery retry, performance monitoring, and troubleshooting, Notification Services retains

information about the delivery of notifications in the notification table. Delivery channels invoke a delivery

channel callback to report delivery successes and failures for individual notifications. The callback updates

the notification table to reflect the success or failure of each notification.

You can configure Notification Services to automatically retry failed delivery attempts, how often retry is

attempted, and how long to retry delivery before marking a notification as failed.

Delivery Options

In addition to standard message-by-message formatting and delivery, Notification Services offers two

options: digest delivery, which groups multiple notifications to an individual subscriber in a single

message; and multicast delivery, which sends a single notification to multiple subscribers. For example:
• If multiple notifications are likely to be sent to individual subscribers, such as price information for

multiple stocks, the developer can group notifications using digest delivery. All of the subscriber's

notifications within a notification batch can be grouped and sent as a single notification. Digest

delivery reduces the formatting and distribution load on the system.

• If an application produces notifications that are likely to be the same for many subscribers, such as

stock prices or weather reports, the developer can choose multicast delivery. This method allows

notifications to be formatted once and then sent to multiple subscribers, which improves performance

by reducing the formatting load on the system.

Notification Services Programming Framework

The Notification Services programming framework facilitates quick application development. The primary

task for application development is to create the application definition file (ADF). Depending on your

application, there might be some additional tasks.

Developing a notification application using the standard components typically requires the following steps:

1. Define the application in the ADF. This file contains information about events, event providers,
subscriptions, notifications, and application settings. Using this file, you define the structure of data,
queries used to process data, how notifications are formatted and delivered, and operational
parameters for your application.

There can be a few additional tasks, depending on the entries in the ADF. For example, if you use the

file system watcher event provider, you must create an XML Schema definition language (XSD) file

that defines the XML event schema. If you choose to format notifications using XSLTs, you must

create one or more XSLT files that convert the notification data into a readable message.

2. Create a subscription management application using the Notification Services API. The Notification
Services API provides a number of classes (for managed code) and interfaces (for unmanaged code)
to simplify the collection and submission of subscriber and subscription data.

When you are ready to test or deploy the application, do the following:

1. Configure an instance of Notification Services by creating a configuration file. An instance is a named

configuration of Notification Services that hosts one or more applications. The configuration file
defines the name of the instance, names the applications hosted by the instance, and configures
databases, protocols, and delivery channels for the instance.

2. Use the NSControl Create command to create the instance and then use NSControl Register to
register it. NSControl Create creates the instance and application databases. NSControl Register
registers the instance of Notification Services, and optionally creates the NS$instance_name service
that runs the Notification Services engine and the performance counters used to monitor the instance.

3. Activate the subscription management application.

If you use Microsoft Visual Studio® .NET for application development, you can use it to create the ADF,

subscription management application, and configuration file. Also, NSControl commands can be run from

Visual Studio .NET using batch files.

Integration with Other Technology

Notification Services applications can capture events from multiple sources and send notifications to users

and applications.

Notification Services provides several mechanisms for capturing events from external processes and

applications. Notification Services includes a set of standard event providers that can capture data from

common event sources such as XML files or SQL tables. Developers can write custom event providers

using managed APIs, unmanaged APIs, and SQL Server stored procedure APIs to capture events from

other event sources.

Notification Services can send notifications using several delivery protocols. Common protocols like Simple

Mail Transfer Protocol (SMTP) and a file protocol are included with Notification Services. The product also

contains a configurable HTTP protocol, which can be customized to implement a variety of HTTP and

SOAP-based delivery protocols.

Use with Other Microsoft Technologies

Notification Services integrates with other key Microsoft technologies to gather notification content and

deliver notifications to subscribers. The following examples illustrate how Notification Services can

integrate with these other technologies.

.NET Alerts

Notification Services and Microsoft .NET Alerts are complementary technologies. After Notification Services

generates notifications, the .NET Alerts Web service can deliver the notifications to subscribers using a

variety of devices, such as e-mail, Microsoft Windows Messenger, and mobile phones.

Message Queuing and BizTalk

Messages from a queue can be events to a notification application, and notifications can be sent to

Message Queuing queues (also known as MSMQ queues) or to Microsoft BizTalk® through custom delivery

channels.