Overview of Notification Services

Microsoft SQL Server Notification Services is a set of schemas and APIs for developing applications that generate and send notifications to subscribers, and an engine that runs those applications.

A notification application can be thought of as a "push" application. People (or applications) subscribe to the application, and the application sends information of interest to the subscribers. This enables you build applications that send focused and personalized information to your enterprise, customers, and partners.

Notifications are generated based on the occurrence of an event or based on a schedule defined by you or the subscriber. You can choose to support one or multiple delivery protocols, such as email, Short Message Service (SMS), or raw XML, and format the notifications accordingly.

If your application is for an international audience, you can use the built-in support for multiple formatting options and time zone management. For example, if you are using the built-in Extensible Stylesheet Language Transformations (XSLT) content formatter, you can create one transform per combination of language and device type, such as French cell phone, English cell phone, French email, and English email.

As soon as you learn the basics of the platform and framework, you can quickly define notification applications with Transact-SQL and XML or managed code, and then deploy those applications on SQL Server 2005, a robust and reliable data management platform.

In SQL Server 2005, Notification Services is available in Enterprise Edition, Standard Edition, Developer Edition, and Evaluation Edition.

Notification Services Architecture

To understand the Notification Services tools, it's important to understand the basic architecture of Notification Services. Understanding the architecture will make it easier to understand why the tools work the way they do.

Notification Services uses the concepts of applications and instances. An application is a solution for particular categories of notifications, such as credit card or sports-related notifications. An instance of Notification Services hosts one or more applications.

Applications are separate from each other, which enables you to isolate application data and to tune the performance. However, applications share subscriber and delivery channel information through the hosting instance. Figure 15-1 shows the relationships between applications and instances.

Figure 15-1. Notification Services instances and applications.

As illustrated in Figure 15-1, applications share subscribers, subscriber devices (such as email addresses and cell phone numbers), and delivery channels (such as email servers or SMS servers) through the hosting instance. However, application data is isolated from other application data. In fact, each application can have its own database (which is why Figure 15-1 does not illustrate the architecture with database diagramshow you use databases for SQL Server 2005 Notification Services is quite flexible). If multiple instances and applications share the same database, their objects are isolated from each other through the use of database schemas.

Notification Services is also very flexible about how you design applications. Instead of having three finance-based applications (Investments, Banking, and Credit), you could have one application that supports the multiple types of events, subscriptions, and notifications. How you use instances and applications depends on how you want to isolate data versus how you want to share basic application execution settings.

The Notification Services Engine

An instance of Notification Services is controlled by a Notification Services engine. This engine runs event providers, generators, and distributors. For example, if you are using the built-in file-watcher event provider, the engine monitors a folder for XML files and then submits the data to the instance of Notification Services. The generator initiates the processing of events and subscriptions, and the distributor formats notifications and sends them to delivery channels.

In Notification Services 2.0, the engine was always one or more Windows services named NS$instance_name. In SQL Server 2005, you can choose to host the Notification Services engine in your own application or process. In either case, the engine can be located on the database server, on a remote server, or on multiple servers to scale out event processing and notification distribution.

In addition to components run by the engine, instances can use external (non-hosted) event providers and subscription management interfaces. Figure 15-2 shows how all these components work together:

Figure 15-2. How Notification Services components work together.

Building Notification Applications

To build an application, you define schemas and properties for events, subscriptions, and notifications, and then you define operational settings. You can define an application in an XML application definition file (ADF) or using the Notification Services Management Objects (NMO), a managed-code API. ADF and managed code samples are provided in SQL Server Books Online.

There are no specialized tools for developing a Notification Services application. If you are building an application with XML, you can use your favorite XML editor. If you use SQL Server Management Studio, you can use F1 help to get additional information about the XML elements. If you are using NMO, you can use Visual Studio 2005 or other development environments of choice.

In addition to building the core application, you also need to determine how to manage subscriber and subscription data. For many applications, the subscription management interface is a Web or Windows application.

New in SQL Server 2005

You can now insert basic subscriber and subscription data into views that Notification Services creates during application deployment. This was added primarily to simplify application development and testing.

You may also choose to develop custom components for gathering event data and distributing notifications. This is optional and depends on the systems into which you are integrating your Notification Services applications.

Defining Instances of Notification Services

To define an instance of Notification Services, you associate applications with the instance and then provide information such as the name of the instance and the name of the SQL Server instance that hosts the Notification Services data. You also define shared components, such as custom delivery protocols and the delivery channels used to deliver notifications from the instance's applications. You can define an instance in an XML instance configuration file (ICF) or using the Notification Services Management Objects (NMO). ICF and managed code samples are provided in SQL Server Books Online.

Again, there are no specialized development tools for Notification Services. Use your favorite XML editor, SQL Server Management Studio, or Visual Studio 2005 to define an instance.

Deploying and Managing Instances of Notification Services

After you have defined an instance and its applications, you deploy the instance, using SQL Server Management Studio, the NSControl command line utility, or, if defining the instance and its applications programmatically, the Notification Services Management Objects (NMO) API. Deploying an instance requires Notification Services to create database objects; for the instance to be registered, enabled, and started; and for all applications that interact with the instance to have the proper permissions. This is all documented in the "Common Deployment and Management Scenarios" section of this chapter.

New in SQL Server 2005

You can now deploy Notification Services instances and applications into existing databases. For the instance and each application, you can define the name of an existing database and a schema for the objects.

After deployment, you can use the Notification Services tools to perform management tasks such as updating instances and applications, or temporarily disabling an instance or application for system maintenance.