Notification Services is one of the features included in SQL Server 2005. As the
name implies, Notification Services are services which send notifications to
the interested entities based on what they would like be notified on. The
addition of Notification Services to SQL Server 2005 has inherent advantages as
most of the notifications are based on data changes (or additions). Combining
Notification Services with SQL Server makes applications more scalable without
hurting performance. To put it in simple terms, Notification Services are
services that check if any event has occurred on the specified data, check if
any entity has subscribed to be notified when that event occurs, and sends the
notification to that entity. It looks simple, but the architecture of
Notification Services makes it so flexible that you no longer have the pains of
implementing features such as polling events, scheduling, formatting and
delivery of notifications. These features are built in to Notification Services
for easy integration and development.
For example, I would like to be notified by email/SMS or when stock
prices of a particular company rise or fall below a pre-determined mark.
Another example, I want my cell phone to play a different tune when my flight
gets delayed and timings have been changed. There are hundreds of situations we
come across and want our lives to move faster than ever. That’s where
Notification Services comes into picture.
Architecture
The following terms need an introduction to understand the architecture.
-
Event: An event is an action that occurred affecting the specified data.
-
Subscriber: Subscriber is an entity interested in being notified when an event
occurs.
-
Subscription:Subscription is an act by which subscriber describes when and what
he wants to be notified as. (Subscriber specifies that he wants to be notified
when stock price goes more than $100.)
-
Notification: Notification is a mode/channel of communication. Email, SMS, data
files are a few examples.
Notification Services consists four (4) major building blocks: Subscription,
Events, Generator, Delivery (notifications). Subscription data can be added
using (SMO) Subscription Management Objects to Notification Services
application. Events get populated to events table with the help of Event
providers. Once events are populated into events table, the generator wakes up
(it depends on settings here – generator can be event driven or schedule based)
and starts processing rules. The rules are attached with subscriptions and the
generator checks to see if any events match them. If matches are found, the
generator starts creating notifications and fills the Notifications table. Once
notifications arrive in Notifications table, the distributor (again based on
scheduling configuration) wakes up and starts processing each notification,
formats it and sends them using specified channel.
Adding Subscription Data:
Subscription as explained above is a rule/ set of rules that specify what types
of events the subscriber is interested in. Notification Services exposes a set
of managed API’s to add subscriber and subscription data.
Subscription management application can be any ASP.NET application or a Windows
application which accesses the Notification Services Service (the database) and
adds subscriber, subscriber device and subscription information. Subscriber
information is generally a unique ID (string usually), where device information
includes delivery device type (Cell phone or PC) and device address (ex: phone
number). Subscription data depends on the type of Notification Services
application. For a stock notifying application, subscription data might include
symbol of the company. Microsoft.SqlServer.NotificationServices namespace
includes set of objects to add this information.
When configuring a Notification Services application, a developer needs to
specify the schema of Subscription table in a configuration file (known as
Application Definition File – ADF. Check ADF section for more information).
Along with the schema of subscription table, event rules must be specified.
These event rules are nothing but SQL statements or Stored procedure calls
which populate Notification tables. Generally, these rules are insert
statements created by joining subscription and event tables, to fill up
notification tables. Each event rule must be mapped to an event class
indicating that subscription is based on that event table.
Collecting Events:
Events are collected and inserted into event tables using Event Providers.
Notification Services provides FileSystemWatcher, SQL Server and Analysis
Services as Standard event providers. Developers can extend and write custom
event providers which insert into events table. The structure of the events
table should be specified in the ADF file before creating the Notification
Services application. Providers also need to be specified in the Providers tag
in the ADF file. The FileSystemWatcher event provider watches a particular
Windows folder, for a particular type of file. When event data is available, it
starts processing the file and puts them into events table.
Note: If event data is expected in XML format, the file schema must be specified
in order to be processed.
Notifications Configuration:
The Generator evaluates subscriptions on event data and generates notifications
into the Notifications table. The schema of the Notifications table must be
specified in the Notifications tag of the ADF file. Each notification class can
be attached with a set of content formatters. A content formatter is used when
distributor tries to format the notification into an end result (ex: a content
formatter can be an XSLT file: the input to XSLT file is an XML of structure
<notifications><notification><fields/>..). Finally a
notification should be added with at least one delivery protocol (ex: File,
SMTP, etc.).
Application Definition File (ADF):
The ADF file is the main input to the Notification Services application. It
contains the complete information which is required to create a Notification
Services application. The structure of Notification Services includes a
Notification Services instance and each Notification Services instance can
contain one or more Notification Services application. NSControl is the
command line utility to create, update, and delete Notification Services
instances and applications. If you use the SQL Server 2005 beta, you can use
the SQL Server Management Studio to create Notification Services instances
(check MS-Help on how to create Notification Services instance and
applications).
To explain how Notification Services work, I am going to take an MS-Help sample
and explain the code.
Big Shot Sample:
The Big Shot sample is a simple Notification Services sample application.
Theoretically people would be interested in some executive’s (aka “big shot”)
activities and would like to be notified when he is free or on a business trip.
For example, say I would like to meet Mr. President and I would like to know
when he is free for next week. All notifications should be sent to my in-box.
Though this sample might seem bit odd (peeping into someone’s personal life),
lets assume this big shot is publicly accessible.
Events
The events table should contain Name, Nick-Name, Action and Description. Action
indicates the type of action and description explains the action.
The above creates NSBigShotEventsEvents table in the database (when the
Notification Services instance is created). Event Provider is the one that
inserts into this table. The following part of the ADF specifies the provider
configuration.
Our application allows subscribers to poll for events based on the big shot
nick-name and action. So the ADF file subscriptions section looks like this.
The above indicates what columns the NSBigShotSubscriptionsSubscriptions table
includes. General practice is to include device name, subscriber locale (for
language support) and any other application specific columns. You can also
create indexes on these tables. The EventRules node performs inserts into the
Notifications table based on a mapping between Events and Subscriptions table.
The Notifications section in the ADF describes the type of formatting and
delivery for the notifications. In our example, I have configured to use the
XSLT formatter with File and SMTP delivery. Notification Services creates a
table named NSBigShotNotificationsNotifications with the specified schema.
Any additional settings such as directory paths should be included in the
app.config file, which will also have a reference to the ADF file.
To summarize, Notification Services is such a robust and powerful technology. It
will make lot of business processes simple and ease to maintain. What we
haven’t covered in this article is Creating Custom Event Provider, Custom
Formatters and Custom Delivery.