Section 18.1. Architecture

18.1. Architecture

Notification Services applications are based on a subscriber/subscription model. Here are some key terms used to describe the entities participating in a Notification Services application:

Subscriber

A user or application that requests and receives the notification

Subscription

A request for information, delivery mechanism, and destination for requested notifications

Event

A piece of information or an occurrence in which the subscriber is interested

Notification

A message containing the information requested by the subscriber in the subscription

Figure 18-1 shows the relationship between these entities.

Figure 18-1. Relationship between Notification Services entities

The Notification Services platform stores system data, and it generates and distributes notifications. It comprises the following:

• Notification Services engine, which contains the provider host, generator, and distributor

• Notification Services database

A Notification Services application is hosted in a Notification Services instance. The application generates and sends messages to the application's subscribersusers or other applications. The subscriber creates subscriptions to the application. The application monitors and collects events . Notification Services matches subscriptions to events and generates, formats, and sends a notification to the subscriber when an event and subscription match. The application database stores event, subscription, and notification data and metadata about the Notification Services application. The applications in a Notification Services instance can share subscribers and delivery mechanisms, which allows them to be administered as a group.

A subscription management application manages subscriber and subscription information in Notification Services. Subscription management is the process of managing the subscribers, the information they are interested in (subscriptions), and where to send notifications (device information). Subscription management is handled by a Windows or web application that uses subscription management objects supplied in the Notification Services Management Objects (NMO ) classesa collection of classes used to create and administer Notification Services instances and applications programmatically. The subscription management classes are used to write and read subscriber, subscription, and subscriber device data from Notification Services.

To support both Notification Services applications and subscription management applications, Notification Services provides an API that stores and retrieves subscriber and subscription information, collects and stores event data, matches subscriptions and events to generate notifications, formats the event data into messages according to delivery protocol, and sends messages to subscribers. The remainder of this section describes this process in more detail.

An event provider collects event data from various sources and submits this data to a Notification Services application, which uses one or more event providers . Notification Services ships with three standard event providers:

File System Watcher event provider

Triggered when an XML file is added to a watched directory. The ClassName for this event provider is FileSystemWatcherProvider.

SQL Server event provider

Uses a T-SQL query to get information from a database and create Notification Services events based on the result. The ClassName for this event provider is SQLProvider.

Analysis Services event provider

Uses a static or dynamic multidimensional expression (MDX) query to get information from an Analysis Services cube, and creates Notification Services events based on the results. SQL Services Analysis Services (SSAS) and MDX queries are discussed in Chapter 18. The ClassName for this provider is AnalysisServicesProvider.

You can develop a custom event provider if the standard event providers do not meet your needs.

An event provider is either hosted or nonhosted. A hosted event provider runs within Notification Services, either continuously or according to a schedule. Nonhosted event providers run as external applications and submit events on their own schedule.

An event class represents one type of event that can be submitted to a Notification Services application and used to generate notifications. An event class definition includes field names and data types for the event and supporting data. The event class is used to implement the underlying SQL Server database objects for storing the event data and supporting data.

An event chronicle is a supplemental storage tables for event data. An event chronicle is generally used to store most-recent event data to support scheduled subscriptions . This data is updated as it changes and used whenever a scheduled subscription is evaluated. An event chronicle rule contains the T-SQL queries that maintain the event chronicle data in the underlying SQL Server tables.

A subscription class represents one type of subscription to a Notification Services application. The subscription class definition includes both fields for storing subscription data and a notification generation rule that matches events to subscription data. The subscription class is used by SQL Server to implement the underlying database objects for storing the subscription data and supporting data.

Once events are collected by the event provider, the generator processes subscriptions against those events by applying notification generation rules . The generator settings include which computer runs the generator and how many threads the generator can use when it processes application rules.

A notification class represents one type of notification produced by a Notification Services application. The notification class definition includes fields and data types defining the data that is sent to subscribers, information about the content formatter, and information about how the delivery protocols are used to deliver notifications. The notification class is used to implement the underlying SQL Server database objects for storing the notification data and supporting data.

A distributor is run by the Notification Services engine and governs notification formatting and delivery. Every distributor quantuma configurable intervalthe distributor looks for a work itema group of notificationsto process. If the distributor finds a work item, it calls the content formatter to transform the notification data and send the formatted notifications to the subscriber using the specified delivery protocol.

The content formatter transforms raw notification data into readable messages in each combination of subscriber locale and device. A content formatter is required for each combination of locale and device. The formatted message can contain raw notification data, dynamic formatted data that is calculated at formatting time, and static text specified by the content formatter.

A delivery channel represents a delivery endpoint. Formatted notifications are sent to one or more delivery channels . These in turn package the notifications into delivery protocol packets and send them to the services that deliver the notification messages to a subscriber. Notification Services includes the following standard delivery protocols:

Simple Mail Transfer Protocol (SMTP)

Creates and routes notification messages for delivery by an SMTP service.

File protocol

Creates and routes notifications to a text file; intended for application testing.

You can develop a custom delivery protocol if the standard ones do not meet your requirements.

In addition to standard message-by-message formatting and delivery, Notification Services offers two options: digest delivery, which groups multiple notification messages to a subscriber into a single message, and multicast delivery, which sends a single notification to multiple subscribers.