Frequently Asked Questions
Microsoft has compiled the following list of questions commonly asked by users of Notification Services.
What is the difference between Notification Services and SQL Server Agent?
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 based on data values using triggers, SQL Server Agent was not designed or intended to scale to thousands or millions of users. Notification Services, because of its scalability model, 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.
Can I run multiple notification applications 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.
How long does it take to generate a notification from an event?
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 and when the event provider submits that event in an event batch is one cause of latency.
- The generator must "wake up" to generate notifications. The generator wakes up on a schedule determined by the value of the <QuantumDuration> element in the <ApplicationSettings> node of the application definition file (ADF). 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 evaluated at one time, the longer this process takes. Optimized rules and well-chosen indexes can reduce matching latency.
- The distributor must "wake up" to distribute notifications. The distributor wakes up on a schedule determined by the value of the <QuantumDuration> element in the <Distributor> node of the ADF. 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 Server has no control over the latency of sending notifications.
Each sample application has several batch files in a BuildScripts folder. What are these files?
Microsoft recommends that you do not use these scripts when deploying an instance of Notification Services to production servers. For information about production deployment, see Deploying an Instance.
Do I need to install Microsoft Visual Studio .NET to develop Notification Services applications?
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 configuration file. You can create these XML files using any text or XML editor.
If you are building custom event providers and content formatters, you can use the Microsoft Visual Studio .NET development environment to create these objects. However, you are not required to use Visual Studio .NET. You can use any text editor to write the code; you must install the Microsoft .NET Framework SDK and compile your code using the associated compiler.
The samples are packaged as Visual Studio .NET solutions, but you do not need to use Visual Studio to run them. The scripts to build and run the samples can be run from a command prompt. For more information, see Programming Sample Structure.
If you install the Notification Services documentation after installing Visual Studio .NET, the documentation is integrated into the Visual Studio .NET Help system. This provides context-sensitive help to the Notification Services documentation.
Comparing the hosted event provider with the independent event provider, what benefit does one provider have over the other?
Independent event providers are useful if you have existing infrastructure that can submit events, such as a customer relations management application or a Web application. Independent event providers are listed in the application definition file (ADF) only so that they can be referenced by subscription classes.
I already have a subscription management application written in unmanaged code. Can I call your API from my application?