Frequently Asked Questions About Notification Services

Microsoft has compiled the following list of questions commonly asked by users of Microsoft Notification Services.

SQL Server Agent was created specifically to send messages to SQL Server administrators or to perform predefined tasks based on server or database conditions.

In contrast, Notification Services collects data from just about any source, matches the events to subscriptions defined by many users, and sends formatted messages using almost any protocol to almost any device that can receive messages.

Although you can customize SQL Server Agent to send messages to many users using triggers, SQL Server Agent was not designed to scale to thousands or millions of users. Notification Services can scale to millions of users, sending millions of notifications per day.

Also, as a development platform Notification Services provides features that reduce the time required to get an application up and running. SQL Server Agent is not a development platform, so it does not offer similar features.

For more information about Notification Services, see Introducing SQL Server Notification Services.

Yes. You deploy instances of Notification Services; each instance can host one or more applications. You can run multiple instances on one server; you also can run multiple versions of Notification Services on one server.

To determine how many applications to run on one server, you must look at the processing load each application is likely to place on your server. If you run too many applications on one server, performance degrades.

For more information, see Planning a Notification Services System.

First, not all subscriptions are event triggered. Some subscriptions specify a schedule for notifications. In this case, notifications are sent according to the defined schedule, not when the event arrives.

For event-triggered notifications, the latency between the occurrence of an event and the delivery of the notification depends greatly on the application design. Here are the causes of notification latency:

• Events must be submitted to Notification Services. The time between an event's occurrence and when the event provider submits that event in an event batch is one cause of latency.
• The generator works on a schedule determined by the value of the generator's QuantumDuration property. If the quantum duration is 60 seconds, there can be a 60-second delay before an event batch is used to create notifications.
• The generator must match events to subscriptions in order to generate notifications. The matching is performed by one or more Transact-SQL queries. The performance of these queries determines the latency involved with generating notifications. In general, the more events and subscriptions that are evaluated at one time, the longer this process takes. Optimized rules and well-chosen indexes can reduce matching latency.
• The distributor works on a schedule determined by the value of the distributor's QuantumDuration property. As with the generator, if the quantum duration is 60 seconds, there can be a 60-second delay before a notification batch is processed by the distributor.
• The distributor must format notifications and package them for delivery. The formatting is performed by a content formatter object. Complex formatting can take longer to perform than simple formatting, and sending the formatted notification to a delivery service also takes some time. For example, posting a notification to an HTTP server can take up to 30 seconds.

After the distributor sends the notification to the delivery service, such as a Simple Mail Transfer Protocol (SMTP) server, Notification Services has no further control over the latency of sending notifications.

No, Microsoft Visual Studio is not required, but it can make development easier.

If you are developing an application that uses the standard event providers and content formatters, you can build the application by creating an XML application definition file (ADF), and then defining an instance to host the application by creating an XML instance configuration file (ICF). You can create these XML files using any text or XML editor.

If you want to build an application using Notification Services Management Objects (NMO), or you are building subscription management interfaces, custom event providers, and content formatters, you can use the Visual Studio development environment to create these objects. However, you are not required to use Visual Studio. You can use any text editor to write the code; you must install the Microsoft .NET Framework SDK and compile your code.

Implementing a hosted provider usually means less development work because the Notification Services instance loads the Notification Services API and maintains the schedule used to activate the event provider. Hosted providers can also be enabled and disabled like other Notification Services components and services.

Non-hosted event providers are useful if you have existing infrastructure that can submit events, such as a customer relations management application or a Web application. Non-hosted event providers are listed in the application definition file (ADF) only so that they can be referenced by subscription classes.

Notification Services supports COM interop for simple subscriptions. However, you cannot create condition-based subscriptions using COM interop because classes in the Microsoft.SqlServer.NotificationServices.Rules namespace do not support COM interop.

For more information, see COM Interop with Notification Services.

Resolving Common Notification Services Issues
Configuring Notification Services Event Logging
Using Event Messages

Getting SQL Server 2005 Assistance