Like most services or applications, Microsoft SQL Server Notification Services is not one monolithic application. It is composed of several smaller components that work together to create a notification application. In order to develop your own notification applications, it is important to have a good understanding of each of these components and how they interact with each other.

Architecture at a Glance

Every notification application is concerned with four fundamental things: subscribers, subscriptions, events, and notifications. However, each of these aspects is composed of one or more underlying components. Let’s take a closer look at how these pieces fit together to form SQL Server Notification Services.

Subscribers and Subscriptions: Subscribers are the people who sign up to use the notification application. They indicate their interest in receiving specific information when an event occurs. Subscribers use a subscription management application to define the events they are interested in and how and when they would like to be notified. The subscription management application creates a subscription for the subscriber in the notification application. Subscribers can be individuals or other applications.

Events: Events are the occurrences that trigger notifications. SQL Server Notification Services must be made aware of these events in order to notify the subscribers. Event providers are responsible for monitoring and obtaining information from external sources. SQL Server Notification Services comes with built-in event providers such as the SQL Server event provider and the File System Watcher event provider. Custom event providers can also be created using the APIs provided.

Notifications: Notifications are created by evaluating the intersection of the subscription data and the event data. Subscription processing compares the event data to the subscription data and generates notifications. Some notification applications initiate notifications as soon as event data is received, while others consider historical information as part of subscription processing.

The Generator: The generator is responsible for subscription processing. It executes rules that compare subscriptions to a batch of events and writes matching entries into a notification table.

The Distributor: The distributor facilitates the delivery of queued notifications. It applies aggregations, formats the notifications, and passes them to the appropriate delivery channel.

Conclusion

SQL Server Notification Services is a highly scalable and flexible add-on to Microsoft SQL Server. Understanding its architecture allows you to leverage its capabilities to develop effective notification applications. By considering the components of subscribers, subscriptions, events, and notifications, you can create a robust and efficient notification system.

Source: Adapted from “The Rational Guide to: SQL Server Notification Services” by Joe Webb from Rational Press.