Types of Event Providers
- 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.
- 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.
- 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.
- 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:
- The SMTP protocol for sending notifications to Microsoft Exchange Server or other SMTP servers.
- The HTTP protocol.
- 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<NotificationClassName> 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 Server90NotificationServices9.0.242XMLSchemas 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:
- Create the instance and application database objects by compiling the instance configuration.
- Register the instance of Notification Services.
- 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.
- 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:
- SQL Server Management Studio
- NSControl utility
- 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.
]]>