Microsoft SQL Server Notification Services Technical Overview

Updated : September 5, 2002

Notification Services Product Team

August 2002

Summary: This white paper introduces Microsoft® SQL Server™ Notification Services. Notification Services is a programming framework for building applications that send notifications to subscribed users, and a server that hosts the applications. This paper describes notification applications, provides an overview of the application development process, provides an overview of the server architecture, and describes how applications are deployed. After reading this paper, you should be ready to use the Notification Services documentation to build and deploy a notification application.

On This Page

Introducing Notification Services
Platform Foundations
Notification Server Architecture
Operational Capabilities
Integration and Interoperability
Administration and Deployment
Conclusion

Introducing Notification Services

Microsoft® SQL Server™ Notification Services is a platform that helps you build notification applications within days, deploy the applications easily, and scale the deployment to millions of users.

The Notification Services platform provides both a development framework and a hosting server:

• The straightforward yet powerful declarative programming framework for notification applications is based on XML and the Transact-SQL language.

• The reliable, high-performance, scalable server that runs the notification application is built on the .NET Framework and SQL Server 2000. The server runs on the reliable and scalable Microsoft Windows® Server family of operating systems. Notification Services has been designed for extensibility and interoperability with a variety of existing applications.

Notification Services is a component of SQL Server 2000.

What is a Notification Application?

A notification application sends messages to users who have subscribed to the application. The messages are typically personalized to reflect the preferences of the subscriber. The messages are usually timely, reflecting information that should be sent to the subscriber immediately or on a pre-determined schedule.

To understand notification applications, it is important to have a common set of terminology:

• A subscriber is an entity (person or application) that has subscribed to an application.

• A subscription is an expressed interest in specific information, such as a stock price or sports team, and the specification of a delivery device.

• The information that subscribers are interested in is collected as events. 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 one or more events.

• A notification is a message delivered to the subscriber-specified device that contains information related to a subscription. A notification might contain a message about a new value for a specific stock or the final score for a game.

• A device is where the notification is sent. The device might be a cellular phone, Personal Digital Assistant (PDA) or e-mail account, specified by the subscriber in a subscription.

The Value of Notification Applications

The value of notification applications is the ability to send information to subscribed users, provide value to both the enterprise hosting the application, and the customer or employee who subscribes to it:

• An enterprise can send focused, relevant communications to its customers. Not only can a notification contain information relevant to customers, it can also contain links that enable customers to browse back for additional information or to send order requests, providing a direct way to increase company revenue.

• Enterprises can also use Notification Services to send important information to employees and partners, providing current communication about projects, processes, and systems. This improves information flow and business efficiency.

• A notification application empowers the subscribers, whether employees or customers. The subscribers define exactly what information interests them and when they want it. The application enables them to receive timely, personalized information on a variety of devices, without having to do anything but read the notification.

Application Processing

Notification Services gathers subscriber, subscription, and events data, and produces notifications based on this data. The following illustration shows five components of Notifications Services, working together to make this happen.

Figure 1: Application Processing

The five components work together in the following ways:

• A subscription management application enables subscribers to submit subscriptions.

• Event providers gather data from an external source.

• A notification application server processes subscriptions based on the current set of events and creates notifications.

• A reliable and secure database stores events and subscriptions, runs Transact-SQL statements and stored procedures, and stores the resulting notifications.

• Delivery channels route the notifications to delivery services, such as Exchange servers, SMS servers or .NET Alert servers.

Users of Notification Services

In a notification application, three groups must participate to develop the application, run the application, and receive notifications:

• Application developers create notification applications. Building an application involves defining logic to manage subscriptions, defining how events are collected and stored, defining how subscriptions are evaluated, and defining how notifications are formatted and delivered.

• System administrators install, configure, and manage Notification Services and applications. The administrator specifies which applications are installed on a given computer, determines how to configure the system for scalability and availability, and configures delivery channels. The administrator also configures and manages the databases where Notification Services stores subscriptions, events, and notifications.

• Subscribers use the subscription management application to subscribe to applications and to modify existing subscriptions. Subscriber devices such as PDAs and cell phones receive notifications from Notification Services.

Business Scenarios

Notification Services can be used for a wide variety of applications, especially in the business-to-customer, business-to-employee, and line-of-business segments. The following scenarios provide motivating examples in each of the segments.

Stock Alerts

Company analysts want to be aware of any significant change in the price of their stock and the prices of competitor stocks. Notifications are sent to each analyst whenever a stock moves by a defined percentage.

Using SQL Server Notification Services, the company develops an application that enables analysts to create subscriptions, each containing a stock symbol and custom percentage. The percentage indicates the percent change in stock prices, either positive or negative.

When a new set of stock prices is available, Notification Services reads the batch of stock events. For each event, the stock price is compared to the opening price of the day, which is stored in a table called an event chronicle. A percent change is computed to match the event to subscriptions. If the percentage meets or exceeds the percentage specified by any analyst, those analysts receive a notification containing the current stock price and the percent change in the price.

When an analyst receives a notification, data is stored in a subscription chronicle. Before a later notification is sent, the application checks the subscription chronicle. If the analyst has received an earlier notification for that stock that day, the analyst does not receive another notification for that stock.

Project Management Updates

A company has several new products in development. Project leads and managers need to keep up with project status. Executives want to know if new product development is on budget.

Using Notification Services, the company develops an application that retrieves data from a SQL Server project database according to a set schedule. The application sends daily project status updates to the management team, and weekly project updates to executives. The information is focused, providing each subscriber with the information required and alleviating the need for the subscriber to search through long e-mail messages or to query the database.

Production Notifications

Production line managers must be aware of production line issues, such as whether there is a slowdown in a section of the line or a piece of machinery is down. The company develops an application to send production-related notifications to production line management.

Each manager creates subscriptions for his or her specific areas of production and events. The software that monitors the production line gathers data and stores it on the LAN. Notification Services retrieves this event data and processes the subscriptions. The resulting notifications are formatted and sent to a paging system. As a result, when conditions on a production line match subscription values, production line managers are paged.

Value Proposition

The ability to send focused; relevant information to subscribed users provides value to both the enterprise hosting the application, and the customer or employee who subscribes to it:

• An enterprise can send focused, relevant communications to its customers. Not only can a notification contain information relevant to customers, it can also contain links that enable customers to browse back for additional information or to send order requests, providing a direct way to increase company revenue.

• Enterprises can also use Notification Services to send important information to employees and partners, providing current communication about projects, processes, and systems. This improves information flow and business efficiency.

• A notification application empowers the subscribers, whether employees or customers. The subscribers define exactly what information interests them and when they want it. The application allows them to receive timely, personalized information on a variety of devices, without having to do anything but read the notification.

Most enterprises have accepted the value of notification applications, and some are actively deploying solutions in this space. However, this usually involves custom software infrastructure to implement the specifics of the application, as well as much of the "plumbing" needed for reliability and manageability. Further, as the application needs to grow by adding new features or scale with increasing adoption, custom infrastructures usually run into limitations that require expensive redesign and reimplementation.

The real value of Notification Services is that it is a platform that has implemented the infrastructure and feature capabilities needed for a wide variety of enterprises. This enables the enterprise to focus development resources on the specific features of the actual application (dramatically reducing development and testing costs), and to optimize the deployment and operations issues (dramatically reducing long-term supportability costs).

Positioning With Regard to Other Microsoft Products

Other key Microsoft technologies provide services for gathering content and delivering the information to users: .NET Alerts, Mobile Information Server, and Queuing and Messaging Middleware. Notification Services also works with these technologies.

.NET Alerts

Notification Services and .NET Alerts are two complementary technologies.

Notification Services is used by enterprises to generate notifications. Notification Services will be installed within the enterprise where it executes notification applications that manage subscriptions, process events, and generate notifications. The generated notifications are formatted and then distributed through a delivery channel.

Microsoft .NET Alerts is a Web Service used to deliver notifications to users on a variety of devices including Instant Messaging (IM) clients and mobile phones. The .NET Alerts service can receive messages from a delivery channel for Notification Services, thereby creating an end-to-end solution. There are enterprise solutions in deployment today that use the Notification Services product along with the .NET Alerts service in this fashion.

Queuing and Messaging Middleware

Microsoft has server products in the queuing Message Queue Server (MSMQ) and messaging (Microsoft Biztalk®) market segments. These products are complementary to Notification Services. Messages from a queue can act as event inputs to a notification application. Notifications generated from an application can be sent to MSMQ or Biztalk through a Notification Services delivery channel.

Platform Foundations

Notification Services was designed to provide a scalable notification platform with easy application development using well-known tools and standards.

Designing for Scale

In all notification applications, the basic requirement is to evaluate all the subscriptions at the right times. Some subscriptions are event-triggered, meaning they must be evaluated when events arrive. Other subscriptions are schedule-based, meaning the subscriptions are evaluated at specific times.

For small systems, requirements can be met by defining each subscription as its own query, and running the queries at the appropriate times. However, when there are large numbers of subscriptions, running thousands or millions of individual queries does not scale well.

To solve this problem Microsoft SQL Server Notification Services relies on the fact that subscriptions typically share a common structure. Millions of users may want to get stock price notifications. Thousands of users may want to know the result of a sporting event. If subscriptions share a common structure, the subscription queries can be parameterized. In essence, there is a single or a small number of subscription templates, and individual subscribers fill out parameters to customize the template.

The impact of this design is tremendous. Instead of treating individual subscriptions as queries, Notification Services treats individual subscriptions as parameter data. The evaluation of large numbers of subscriptions becomes a set-oriented data processing problem, for which database engines are well suited. This is the foundation of the Notification Services programming framework.

In this model, event-triggered subscriptions are evaluated by executing a database join between new events that have arrived and a large set of subscriptions. Expanding this model, Notification Services can implement the following broad categories of subscriptions that are:

• Event-triggered subscriptions as described above.

• Evaluated according to a schedule.

• Based on event history.

• Based on application state.

• Utilizing external databases.

Using the set-based Notification Services model, application developers can quickly create a robust and scalable notification application. Application development is easy, and performance gains are large.

Application Development

Microsoft Notification Services applications describe the data and operation for a single type of notification. For example, one application might provide weather alerts, while another application provides stock updates. This allows Notification Services to take advantage of a set-oriented programming framework.

The actual application definition describes how events are collected, how subscriptions are managed and evaluated, and how the resulting notifications are formatted and delivered. The application developer defines an application by creating the following components:

• The core application definition: An Application Definition File (ADF) defines the central logic of the application. It has the following components:

  • Event definitions specify the structure of event data, the event providers that collect the data, and the structure of any event chronicles used by the application.

  • Notification definitions specify the structure of raw notification data, the formatting for the messages that is sent to subscribers, and the delivery protocols used to send the messages.

  • Subscription logic defines how subscriptions are evaluated. Transact-SQL statements match subscriptions to events, or evaluate subscriptions at certain recurring times. The subscription logic is parameterized in a well-defined and regular manner, so that individual subscriptions can personalize the subscription logic.

    A subscription schema defines the structure of the subscription parameters, and evaluation times define when subscriptions are evaluated.

  • Operational settings enable the application developer to enhance the behavior and the performance of the application when executed by Notification Services.

• A subscription management application that provides the user interface for subscribers to update their information for one or more applications.

• Optionally, developers can create their own event providers, content formatters or delivery protocols. For many applications, these custom objects are not necessary because standard event providers, content formatters, and delivery channels are provided with Notification Services.

Development Environment

Applications are developed in the Microsoft Visual Studio® environment. A Notification Services application is described by a Visual Studio solution. All of the standard and familiar Visual Studio tools, including an XML editor, database server explorer, ASP.NET editor, and more can be used to build applications rapidly.

Notification Server Architecture

The following illustration shows the three main components of Notification Services that process events and generate notifications: the event provider, the notification generator, and the notification distributor.

Figure 2: Notification Services Components

• Although the subscription management application is not an internal component, it is an essential component because it is the interface for collecting subscription data.

• Event providers collect events and submit the event data to Notification Services. An application can use standard event providers provided with Notification Services, or application developers can create custom event providers.

• The notification generator processes subscriptions and creates notifications based on the current set of events. The application developer defines the operation of the notification generator.

• The notification distributor formats notifications and sends them to the subscriber through a delivery service. Application developers define the transformation from raw data to a formatted notification.

Subscription Management

Subscription management is the process of taking information from users and adding the data to Notification Services databases. The data about subscribers and their delivery preferences is called subscriber data. The data, about the individual events the subscribers are interested in, is called subscription data.

Notification Services stores the subscriber and delivery information in a central Notification Services database, and it stores individual subscriptions in application-specific databases. This allows applications to share the global subscriber data while separately storing subscriptions for each application.

Subscription management is handled by a custom subscription management application written by the application developer. This application, which can be a Web application or standard Windows application, takes the subscriber and subscription data and writes it to the proper databases. Developers use subscription management objects supplied with Notification Services, which simplifies application development. The following illustration shows how the subscription management objects provide an interface to the databases.

Figure 3: Subscription Management Architecture

The notification generator uses subscription data to generate notifications, and the notification distributor uses subscriber data to format and distribute the notification data.

Event Collection

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 an event provider.

An event provider obtains event data from an external event source and submits the data to Notification Services using an event interface. The event provider writes the data to an event table in batches. When the provider commits a batch of data to the event table, the notification generator can then process the batch and create notifications, either as soon as the batch of events arrives or according to a schedule.

Four APIs are available for submitting events: a managed API, an XML API, a SQL API, and a COM API that uses the managed API. The following illustration shows a high-level view of how these providers function.

Figure 4: Event Collection Architecture

These four APIs are used as follows:

• The managed API uses event and event collector objects for submitting events. Using the name of the fields in the event table, an application submits data and then commits the data using the event collector interface.

• The COM API exposes the .NET classes as COM interfaces, allowing you to submit data from a COM object to the managed API.

• 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 interface, which then writes the events to the event table.

• The SQL API uses stored procedures to load event data from database objects. Typical ways of using the SQL event provider are to invoke the provider using a stored procedure or to run a query according to a schedule. The event provider receives a result set and writes to the event table using the API stored procedures.

Event providers can be invoked in a number of ways, depending on where the event providers are hosted:

• Hosted event providers, which run within Notification Services, are either continuously running or are invoked according to a schedule defined in the application settings.

• Non-hosted event providers run as external applications and submit events according to their own settings, such as in response to the click of a button.

Applications developers can configure an application to use one or more event providers. Applications can use standard event providers supplied with Notification Services, such as the Scheduled SQL Server or File System Watcher provider or they can use custom event providers.

Subscription Processing and Notification Generation

After events are collected in the event table, subscriptions can be processed. Evaluating subscriptions according to the collected events is a task for the notification generator.

To generate notifications, the application developer creates an event subscription rule. This rule, written in Transact-SQL, specifies how events and subscriptions relate and any other conditions that must be met to generate a notification.

In an event-driven application, when a single event matches a single subscription, the generator creates a notification. This does not mean the notification is actually sent at that instant. In truth, the generator writes it to an internal notification table. This notification contains data about the event, and references data about the subscriber, the delivery device, and other information required for distribution. The following illustration shows where the generator obtains data from and writes data to when generating notifications.

Figure 5: Generation Architecture

Notification generation can be more complex than matching an event to a subscription. For example, an application might generate a notification only if the new stock price is at least 5 percent more or less than the price in the previous notification for the subscriber. To support state-based notifications such as this, Notification Services use chronicles and multiple rules. Chronicles are supplemental tables where an application can store information such as previous events and notifications. The application can then use the additional rules to either check or update the chronicle tables.

The following types of rules are available to support these and other application functions:

• Event chronicle rules store or update the history of events in chronicle tables defined by the application developer. These tables can contain data the application developer wants to store about individual events. For example, in a stock price application, a chronicle might store the high price for each stock for the day.

• Event subscription rules join events to subscriptions. These rules are executed when a generator receives new event batches. The result set of the join, can be used for the raw notification data.

• Event subscription rules can also use subscription chronicles for subscription state. For example, if a subscriber has already received a notification today, the rule might not generate a new notification.

• Timed subscription rules are executed on a subscriber-determined schedule. These rules can be used to generate notifications at specific system clock times. Timed subscription rules can also use subscription chronicles for subscription state.

These rules fire when events arrive or according to a predefined schedule. After the notification generator executes the rules, any resulting notifications are written to the notification table. From this table, the notifications are ready to be processed by the notification distributor.

Notification Formatting and Delivery

After raw notification data is written to the notification table, each notification must be transformed into a readable notification that is formatted for the destination device and then sent to the device through a delivery channel. This formatting and distribution is the job of the notification distributor.

When a batch of notifications is available, the distributor reads the subscriber data in each notification to determine what formatting is required. The distributor then formats the notification and sends it by way of a delivery channel to a delivery service, such as a .NET Alerts or SMTP server.

Figure 6: Distribution Architecture

Formatting

Part of creating an application is defining how raw notification data is transformed into readable messages. Using a content formatter such as XSLT, the application developer creates a transformation for every combination of device and language the application supports.

When the application is running, 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 formatter object to generate the final notification.

The notification itself can contain a combination of the raw notification data, data that is computed at formatting time, and text specified in by the content formatter. These options allow for professional and user-friendly notification text and the inclusion of Web links.

Delivery

Notification Services itself does not handle the final delivery of notifications. Instead, Notification Services uses delivery channels, which can be thought of as pipes to delivery services such as e-mail gateways or .NET Alerts servers. Notification Services sends the notifications to one or more delivery channels, which package the notifications into protocol packets and then sends them to the delivery service that handles the final delivery.

Notification Services includes the following well-known delivery protocols for notification applications. Multiple delivery channels can be configured for each of these protocols:

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

• The file protocol for sending notifications to operating system files, used primarily for debugging applications.

• An extensible HTTP-based protocol that can be specialized to communicate with a variety of HTTP and SOAP-based delivery services (including the .NET Alerts delivery service).

In addition to these standard protocols, application developers can define custom protocols.

For performance monitoring and troubleshooting, Notification Services retains information about the delivery of notifications in the notification table. This information is initially updated by the notification distributor, but can be updated by the delivery service, providing a way to determine if the message was successfully delivered.

If multiple notifications are likely to be sent to individual subscribers, notifications can be grouped using digest delivery, which sends multiple notifications in one message. Because notifications are processed in batches, only multiple notifications within a batch can be grouped into a digest notification.

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 specify that the distributor can use multicast delivery. This enables notifications to be formatted once and then sent to multiple subscribers, which can improve system performance.

Operational Capabilities

An enterprise system must be secure, reliable, scalable, and available. Notification Services addresses these requirements in the programming framework and in the architecture of the Notification Services server.

Security

A number of design features in the Notification Server product, in the .NET Framework, and in SQL Server, allow application developers and administrators to enforce the end-to-end security of the applications and the overall deployment.

Notification Services uses industry standard Web security models to communicate across the Internet with wired and wireless devices. It uses standard Windows security mechanisms and SQL Server 2000 security mechanisms to protect the server.

Individual Notification Services instances are isolated from each other using SQL Server 2000 security mechanisms. This ensures that multiple instances can be hosted on the same machines while safeguarding the security of each individual instance.

Individual subscribers are isolated from each other because of the programming paradigm supported for notification applications. As a result, each subscription is processed as though it were the only subscription in the system.

Application developers can extend Notification Server by defining their own event providers. These are run as managed code supported by.NET Framework, thereby ensuring that they do not compromise the security and stability of the server.

Reliability

The subscription data managed by Notification Server is stored in SQL Server 2000, a highly robust database server, supporting write ahead logging, and failover clustering.

The processing of events, subscriptions, and notifications in Notification Server is fully transactional, thereby providing additional reliability guarantees. Some delivery protocols (for example, SMTP) do not provide guaranteed delivery of messages – however, the Notification Services platform supports retry logic for such protocols.

It is easy to build reliable event providers and reliable delivery protocols (for example, based on MSMQ), thereby achieving complete end-to-end reliability.

Scalability

Notification Services supports high throughput applications with thousands of incoming events per minute, millions of subscriptions matched, and thousands of notifications delivered per minute on a multiprocessor Windows server. A number of product features also support the ability to scale-up on higher-end hardware. Subscription rule logic may be executed in parallel, deriving scale-up efficiencies in the underlying SQL Server execution engine. Notification formatting and delivery may be executed in parallel, deriving scale-up efficiencies in the Notification Services distributors.

Notification Services can support significantly higher throughputs when deployed in a scale-out configuration. A single Notification Services instance is associated with one SQL Server database server. In a typical configuration, the Notification Services functionality (event provider, generator, distributor) runs on one machine, and the database functionality runs on the database server machine. A single instance can support multiple event providers, and multiple distributors. The ability to scale-out the distributors is important in deployments where there are large notification volumes with significant formatting and delivery overheads. In order to scale-out an application further, the subscriptions may be partitioned across multiple Notification Services instances, each of which operates independently. Since the application model makes the subscriptions independent of each other, such partitioning is natural and this makes notification applications highly scalable. The initial version of Notification Services does not provide facilities to provide a single system image across partitioned instances.

Availability

In a Notification Services instance, all data and state are maintained in the SQL Server database server. Only temporary data is maintained in the event provider, generator and distributor. This is a critical aspect of the design, because the availability of the system becomes dependent on the availability of the database server. SQL Server is a reliable database server with a variety of high-availability technologies; fail-over clustering, log shipping, and transactional replication. The database server can be configured to handle hardware failures seamlessly. Fail-over clustering of Notification Services itself (event provider, generator, distributor) has not been implemented in the initial version. If a machine running one of these components fails, the component needs to be enabled on another machine. However, since there is no state maintained outside the database, there is no potential for loss of information or incorrect behavior.

Integration and Interoperability

An important aspect of any notification application is the ability to integrate events from multiple sources, and the ability to send notifications to many destinations including users and other applications.

Notification Services provides a large number of mechanisms to capture events from external processes and applications. There are managed and unmanaged APIs, as well SQL stored procedure APIs to submit events. If event data can be exported in the form of XML, it can easily be imported into a notification application. Further, event providers written in managed code can be hosted within Notification Services, and invoked automatically when the service is run, with an optional periodic invocation feature. The product ships with some standard event providers that can capture data from common event sources. It is easy to write a new event provider using one of these APIs, and to register the new event provider with the system. Event providers that are hosted inherit security mechanisms derived from the .NET Framework. Consequently, integration with external event sources is easy and secure.

Notification Services also provides the ability to send notifications using a number of delivery protocols. Common protocols like SMTP and a protocol to write notifications to a file are part of the product. The product also contains a configurable HTTP protocol, which can be customized to implement a variety of HTTP and SOAP-based delivery protocols. The deployment model allows for the configuration of multiple delivery channels, with the same protocol or with different protocols. This is very important for purposes of authentication to a delivery endpoint.

Administration and Deployment

A Notification Services system consists of the Notification Services components, databases, one or more subscription management applications, and one or more applications hosted by Notification Services. It is the job of an administrator to properly configure Notification Services, databases, and applications for optimal performance and ease of management.

Administration

The system administrator is responsible for implementing applications in production. Ensuring that applications operate optimally requires careful planning, installation, configuration, management, monitoring, and reporting:

• 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.

• Configuration is the process of creating Notification Services instances. This requires version management and careful planning so that system maintenance and upgrades cause minimal service interruptions.

• Management is similar to the management of SQL Server databases. This involves defining security, performing backups, and running maintenance jobs.

• 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. It is also very important to make sure the delivery service is delivering the notifications.

Through these tasks, the system administrator defines the system configuration and ensures the system is operating as planned.

Deployment Architecture

SQL Server Notification Services integrates with the SQL Server database engine and the system that hosts a subscription management application, such as IIS. The database engine provides storage for application data and, if IIS is used for subscription management, it hosts the ASP-based subscription management applications (and possibly event providers). Together, Notification Services, the database engine, and IIS provide integrated data gathering and data delivery. The following illustration shows how data flows through these systems.

Figure 7: The Flow of Data Gathering and Notification Delivery

The data engine also provides other services required by Notification Services. For example, Notification Services uses the Transact-SQL language to join the event and subscription data in the data engine. Because the data engine has been highly optimized for joins, this integration provides scalable performance gains.

Instances and Versioning

When deploying Notification Services applications, administrators created instances of Notification Services. An instance is a single configuration of Notification Services that hosts a set of applications. Each server can host one or more instances of Notification Services, and each instance is completely independent from other instances.

An instance groups applications, which allows them to share subscribers, and be managed together. An instance shares a single database called NSMain, which stores subscriber and instance data. Each instance also has its own copy of NSService, the Notification Services Windows service, which runs the event provider host, notification generator, and notification distributor components. This allows each instance to be started, stopped, and managed separately.

Since multiple versions of Notification Services can be installed on a single system, the instance defines which version of Notification Services it uses. This combination of instances and versions allows applications to be upgraded or downgraded between versions as needed.

The following illustration shows two instances using different versions of Notification Services. Each instance has its own Windows service, instance database, and a set of application databases.

Figure 8: Multiple Instances of Notification Services

Administrators create an instance by creating a configuration file, and then using a command-line tool 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 allow the configuration of files and file groups.

• A list of applications hosted by the instance.

• Protocols supported by the instance.

• Delivery channel instances for delivering formatted notifications to delivery services.

Monitoring Notification Services

During the execution of Notification Services, the status of the system can be monitored in three distinct ways:

• Status reports: A number of pre-defined reports can be executed to view the state of the system. These reports include snapshots of system status, and current status of internal system structures like queues.

• Performance counters: A number of performance counters are maintained with the operating system. These counters provide information on a number of application-level measures like the number of notifications generated per second, the number of delivery failures per second, and so on. The performance counters can be graphically viewed using the PerfMon tool or a variety of other performance analysis tools.

• Event log entries: Diagnostic information is recorded in the application event log maintained by the operating system. Different levels of logging can be specified (errors, warnings, information, verbose), and the resulting entries can be viewed through the EventViewer tool or a variety of other diagnostic tools. Errors are reported along with well-defined and documented error messages.

Management of Notification Services

A deployed instance of Notification Services supports a variety of management tasks for smooth operation.

• Data backup: The data maintained by the notification application is clearly critical and needs regular backup. SQL Server supports a number of backup/restore facilities and tools, as well as, easy ways to configure them through the Enterprise Manager application.

• Data vacuuming: The Notification Services applications keep collecting event data, and keep generating notification data. Consequently, this data accumulates in the database and needs to be periodically removed. This process is called "vacuuming", and it can be configured directly in the notification application.

• Historical reports: Often operations staff members need to run historical reports to capture application trends over time. These reports are pre-defined by Notification Services, and can be scheduled easily using SQL Server Enterprise Manager.

• Analytical/Diagnostic reports: Occasionally, operations staff or developers need to run diagnostic or analytical reports to identify problems in the system. For example, if an event source has not generated events in a while, it is useful to diagnose when the problem started and why it might be occurring. Notification Services provides a number of pre-defined diagnostic reports that can be used for this purpose.

• Reacting to Problems: Rarely, an application might exhibit a problem related to a bad event feed, an invalid subscriber or a failing delivery channel. To react to these situations, the Notification Services platform provides control commands to disable specific components of the system, and/or specific subscribers. Once the problems have been rectified, the appropriate components can be enabled again.

• Instance updates: Rarely, the notification applications need to be updated to reflect new functionality created by the application developers. The Notification Services platform provides control commands to update a deployed instance with new application logic, without losing the existing subscription data.

Conclusion

Microsoft SQL Server Notification Services make it easy to build a notification application, deploy it, and scale the deployment to millions of users.