Notification Services in SQL Server 2005

SQL Server Notification Services is used for developing and deploying applications that generate and send notifications. Notifications are personalized messages sent to a device that subscribes to them. A subscription defines the preference of the subscriber for a specific type of event. For example, a subscriber can specify a preference to the notification application such as "Notify me when new content is added to the Web site." The notification application in this example is the Web site. The subscriber could be the editor of the Web site or someone responsible for managing its content. The triggering event is the addition of new content. Thus, a notification will be sent to the subscriber when the triggering event occurs. The notification can be scheduled on a weekly, daily, or hourly basis. SQL Server Notification Services can be used to send a notification to a wide variety of devices, such as a subscriber's cell phone, personal digital assistant (PDA), Windows Messenger or e-mail account.

Terminologies in Notification services

1. Subscriber is a person or application that subscribes to and receives notifications.
2. Subscription is a request for specific information to be sent to an e-mail address or a device.
3. Event is a piece of information that the subscriber may be interested in. The triggering event can be something like an increase or decrease in the price of a stock.
4. Notification is a message that contains information about the triggering event.

The basic operation of the Notification Services application can be illustrated as follows:

Notification Services can be built and deployed quickly. The Notification Services are capable of scaling to millions of subscribers. Notification Services consists of

• A simple yet powerful Notification Services programming framework that enables the user to quickly create and deploy notification applications. An application can be developed using XML or Notification Services Management Objects (NMO).
• A reliable, high-performance, scalable engine that runs notification applications. The Notification Services engine is built on the Microsoft .NET Framework and SQL Server 2005.

Advantages

1. Notification Services enable the application to send notifications to its subscribers. The notification can include critical information. These subscribers can be customers, employees, or partners.
2. Notification Services help subscribers by providing them with timely, customized, and personalized services.
3. Notification applications allow users to communicate with mobile subscribers over a wide variety of devices.
4. Notification Services keep subscribers alert by providing them with information whenever and wherever they need it. This helps businesses be more productive.
   
   

Notification Services Architecture

The Notification Services platform provides an interface for collecting subscribers and subscriber data, and contains components that collect events and generate, format, and distribute notifications. The user can also create custom components for doing these functions.

The various components in Notification Services are:

1. Subscription Management Architecture

Subscription management is the process of managing the subscriber, subscription, and subscriber device data. This function is performed by the subscription management interfaces. Subscriber Management objects and views help in the interface development process. The Subscription management interface is usually an ASP.NET Web application. This application is developed using a subscription management API. This API is used to add, update, or delete subscribers, subscriber devices, and subscriptions.

The following diagram shows how a subscription management interface interacts with the Notification Services.

The subscriber and the subscriber device data are stored in the instance and database subscription data in the application database. When a Notification Services application is running, applications typically use the subscription data to generate notifications, and then use the subscriber and subscriber device data to format and distribute the notifications.

When a Notification Services instance is created, Notification Services add three Subscription Management Views that are used to manage subscriber, subscriber device and subscription data. The views are named as follows:

1. NSSubscriberView
2. NSSubscriberDeviceView
3. NS<SubscriptionClassName>View

2. Event Collection Architecture

This is the process of gathering event data from the sources and submitting it to the notification application. The sources could be XML files, databases, or applications. This job is usually done by the event providers. Event providers use the APIs to submit the information to the notification application. The APIs can be event APIs, XML APIs, or SQL Server APIs. The Event Collection Architecture can be illustrated as follows:

The following are ways in which the events are written to the Events table:

1. The event object API uses the Event and EventCollector objects to submit individual 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.
2. 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 XML EventLoader, which then writes the events to the event table.
3. The SQL Server API uses stored procedures to load event data from database objects.

Types of Event Providers

1. Standard Event Provider
   
   Standard event providers are supplied with the Notification Services. The standard event providers can pick XML data from a watched folder, can query SQL Server databases, and can query Analysis Services cubes.
2. Custom Event Provider
   
   Custom event providers provide functionality that is not available from one of the standard event providers. For example, the user 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.
3. Hosted Event Provider
   
   Hosted event providers run within Notification Services. Hosted event providers can run either continuously or according to a schedule defined in the application definition. These event providers are run by a Notification Services component called the event provider host.
4. Non-Hosted Event Provider
   
   Non-hosted 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 a non-hosted event provider.

3. Subscription Processing Architecture

After the events are collected, Notification Services can process subscriptions, generating notifications. Evaluating the events against the subscription 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 visible in an event view. 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 sent as soon as 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.

4. Notification Formatting and Delivery Architecture

The distributor does the job of formatting the notifications and delivers it to the subscribers. After the generator creates a batch of notifications, the distributor separates the batch into work items, with each work item destined for the same delivery channel. The distributor then sends the work item to the content formatter. When formatting is complete, the distributor sends the notifications to the delivery endpoint specified by the delivery channel.

Message formatting is done to transform the raw notification data into a readable message. The formatted message can contain a combination of raw notification data, data that is computed at formatting time, and text added by the content formatter.

Notification Services use delivery channels to deliver the notifications to the delivery end points. Each delivery channel packages the notifications for its protocol and then sends them to the delivery services. The delivery services handle the final delivery to the subscribers.

Each delivery channel uses a specific delivery protocol to a specific delivery endpoint. Notification Services includes the following common protocols:

1. The SMTP protocol for sending notifications to Microsoft Exchange Server or other SMTP servers.
2. The HTTP protocol.
3. The File protocol for sending notifications to operating system files, which is used primarily for debugging applications.

To know the status of the delivery of the notifications, delivery channels invoke a delivery channel callback to report the status of individual notifications. The callback updates the notification table to reflect the success or failure of each notification. The user can view delivery status using the NS NotificationDistribution view or the Notification Services stored procedures.

Application Development of the Notification Services

The Notification Services programming framework facilitates quick notification application development using XML or managed code and Transact-SQL. The primary tasks for application development are to define application properties and to configure an instance that hosts the application.

The Notification Services programming framework supports two methods for defining applications and configuring instances:

• The user can define applications and configure instances in XML files, called application definition files (ADFs) and instance configuration files (ICFs), respectively.
• The user can programmatically define applications and configure instances using Notification Management Objects (NMO). The NMO objects are in the Microsoft.SqlServer.Management.Nmo namespace.

Application Definition File

An application definition file (ADF) is used to build notification applications on the Notification Services platform. The ADF contains metadata that defines the application. This includes the structure of the events and subscriptions that the application accepts as input, and the structure of the notifications it produces. The ADF must be an XML file and must conform to the schema described in ApplicationDefinitionFileSchema.xsd, which is in the Microsoft SQL Server\90\NotificationServices\9.0.242\XMLSchemas folder. Application Definition File templates can be found in SQL Server 2005 Books Online.

Instance Configuration File

An instance configuration file (ICF) is a structured XML file that describes a single instance of SQL Server 2005 Notification Services. The ICF lists the Notification Services applications hosted by the instance and contains metadata about the instance, its delivery protocols and delivery channels, and its database server. The ICF must conform to the ConfigurationFileSchema.xsd schema, which is in the Notification Services XMLSchemas folder.

The user then has to develop the subscription management interface using the subscription management API.

Deploying Notification Services

Deploying Notification Services involves the following tasks:

1. Create the instance and application database objects by compiling the instance configuration.
2. Register the instance of Notification Services.
3. Install the Notification Services engine, which runs hosted event providers, generators, and distributors. This engine can be a Microsoft Windows service, which can be installed when the user registers the instance, or the engine can be hosted by a custom application.
4. If your application uses non-hosted event providers or subscription management interfaces, these components must also be deployed.

Notification Services provide three types of tools for deploying instances:

1. SQL Server Management Studio
2. NSControl utility
3. Notification Services Management Objects
   
   

Conclusion

Microsoft SQL Server Notification Services provides a programming framework that makes developing professional notification applications fast and easy, and provides a platform for running those applications in a robust and scalable environment.