Notification Services is now integrated into SQL Server Management Studio Object Explorer. Using Object Explorer, you can perform most nscontrol command prompt utility tasks, as well as start and stop instances of Notification Services .

You can also use SQL Server Management Studio as your XML and Transact-SQL editor. If you create a SQL Server Management Studio solution for a Notification Services instance, you can easily edit your instance configuration file (ICF), application definition files (ADFs), and Transact-SQL scripts for managing security or administering the instance, and you can then deploy the instance using Object Explorer. For a tutorial that guides you through this process, see Notification Services Tutorial.

To learn more about SQL Server Management Studio, see Introducing SQL Server Management Studio.

In Notification Services 2.0, an application developer defined the complete Transact-SQL action for generating notifications, and subscribers could only provide parameters for the action. In SQL Server 2005, Notification Services supports a new type of action, called condition actions, which allow subscribers to define their own query clauses over a predefined data set.

Using condition actions allows subscribers to fully define their own subscriptions over the data set; however it also reduces the efficiency of generating notifications, because there are often many more conditions to evaluate.

For more information, see Defining Condition Actions.

SQL Server Notification Services supports using existing databases for instance and application data. When you configure a Notification Services instance or define a Notification Services application, you can specify the name of an existing database or the name for a new database. Lastly, you can omit a name to use the Notification Services default database names.

For more information, see Defining the Instance Database and Defining the Application Database.

SQL Server Notification Services has a new management API, Microsoft.SqlServer.Management.Nmo. You can use this API to develop Notification Services instances and applications and to manage those instances and applications.

The Notification Services engine runs hosted event providers, generators, and distributors. In Notification Services 2.0, the NS$instanceName Windows Service, which you can install when registering the instance, ran the Notification Services engine. You can now host the Notification Services engine in your own custom application or process. For more information, see Hosting the Notification Services Engine.

Notification Services has added a new standard event provider to gather event data from Analysis Services databases using MDX queries. For more information, see Analysis Services Event Provider.

Notification Services has added or modified the following views to simplify application development and troubleshooting:

• Notification Services creates one view for each event class defined in an application. This view has the same name as the event class. When you write event-driven (not scheduled) notification generation queries, you typically select events from this view. Now you also can insert event data into this view. For more information, see <EventClassName> View.
  
• Notification Services creates one view for each notification class. You can use this view to review notifications generated by your application. For more information, see <NotificationClassName> View.
  
• Notification Services provides three views for viewing and managing subscriber and subscription data:
  
  • NSSubscriberView lists all of the subscribers for an instance of Notification Services. You can use this view to manage subscriber data. For more information, see NSSubscriberView.
    
  • NSSubscriberDeviceView lists all of the subscriber devices for an instance of Notification Services. You can use this view to manage subscriber device data. For more information, see NSSubscriberDeviceView.
    
  • NS SubscriptionClassName View lists all of the subscriptions for a subscription class. You can use this view to manage basic event-driven subscriptions, but not scheduled or condition-based subscriptions. For more information, see NS<SubscriptionClassName>View.
    

In Notification Services 2.0, notification generation rules had to use the Notify() function to generate notifications. This function used three extended stored procedures. These extended stored procedures hindered performance and added deployment steps.

In SQL Server 2005, Notification Services has removed the Notify() function and now requires your notification generation rules to insert data into a notification view. These INSERT INTO statements, which must be run by the generator, improve the performance of Notification Services. For more information, see Defining Subscription Rules and Migrating Notification Services 2.0 Instances to SQL Server 2005.

Notification Services has also made performance improvements to the data removal process, called vacuuming. Depending on the application and the hardware configuration, you can expect a performance improvement of approximately 150 percent over Notification Services 2.0.

Notification Services has supported Windows Cluster technology since the initial release. If you configure the Notification Services engine as a Generic Service cluster resource, the NS$instanceName Windows service that runs the instance can fail over to other cluster nodes.

In Notification Services 2.0, Notification Services would detect whether the cluster software was installed, whether the cluster was configured, and finally whether the cluster was running. If all three checks succeeded, Notification Services used the default cluster name as the local computer name and then ran the components configured to run on the default cluster name.

To provide better support for clustering, you can now configure a separate cluster resource group for Notification Services, which can fail over separately from other cluster resource groups. When you configure the cluster resource, you must now select the Use Network Name for computer name configuration option. This requires you to specify the network name (which is the virtual server name) as the SystemName value for any Notification Services components that run on the cluster.

For more information, see Using Failover Clustering with Notification Services and Walkthrough: Clustered Single-Server Deployment.