Planning a Notification Solution

Article
12/03/2008

It is important to consider metrics concerning the expected type and volume of input and output from your application before you begin the implementation of your Notification Services application. Careful review of these metrics, combined with a thorough analysis of requirements for your proposed application, will allow you to develop a system that meets your business goals.

Planning Checklist

Use the following questions as a guide when you plan your application.

Will you use XML or managed code to define your application and configure the instance?

SQL Server 2005 Notification Services provides a choice for application and instance development. You can define applications and configure instances using XML by creating one application definition file (ADF) for each application and one instance configuration file (ICF) for each Notification Services instance. Or, you can use the Notification Services Management Objects (NMO) to define applications and configure instances.

For more information, see the following topics:

What is your event source?

Notification Services matches events and subscriptions to generate notifications. Before developing an application, you should think about where you will obtain your events. If the events can be obtained from XML files or databases, you may be able to use the built-in event providers that submit the data to your Notification Services application continuously or on a schedule. If your events are in another format, you might need to submit events directly to an event view, create a custom event provider, or query other data sources for your events.

For more information about event providers, see the following topics:

What databases will you use to store instance and application data? What is the configuration of the Database Engine instance?

When you define a Notification Services application and configure the instance that hosts the application, you can create new databases for instance and application data, or you can use existing databases. You will need to decide if it will be better to store instance and application data with other operational data, or if you want to separate instance and application data into another database.

If the databases you choose have multiple filegroups, you also will need to determine which filegroups you will use to store specific instance and application data.

Work with your database administrator when deciding where and how to configure the databases for your instance and application data. For more information about the options, see the following topics:

What are the schemas of the events and subscriptions you want your application to accept and the notifications you want it to produce? What are the schemas of any chronicle tables you want to use?

When you define a Notification Services application, you document the schemas of your event data, subscription data, and notification data. These schemas are used to create application tables and views. Knowing these schemas will help you quickly develop your application.

Applications can also use event and subscription chronicles to store supplemental event and subscription data. Common uses for chronicles are storing event data for use by scheduled subscriptions and storing historical data about individual subscriptions.

When you define a Notification Services application, you provide queries that join event and subscription data and then insert data into a notification view. Good schema design, and the definition of indexes on the resulting tables and views, help you create optimized notification generation rules, which in turn provide better application performance.

For more information about schemas, see the following topics:

After you deploy an application, changing the event or notification schema will drop and re-create the underlying tables and views. Changing the schema of a subscription class renames the existing tables that store subscription data and requires you to manually migrate old subscription data into new tables.

Do you want to offer scheduled subscriptions, event-driven subscriptions, or both? Do you want subscribers to provide parameters to pre-defined queries, or do you want to allow subscribers to define their own conditions?

Notification Services supports event-driven subscriptions, which are evaluated when events arrive, and scheduled subscriptions, which are evaluated on a schedule. Both event-driven and scheduled subscriptions support basic actions or condition actions.

For more information, see Defining Subscription Rules.

How often do you want to remove older event and notification data?

Notification Services can automatically remove older, expired event and notification data through a process called vacuuming. You configure vacuuming per application when you define an application. For more information, see Configuring Data Removal.

Do you want to use standard Notification Services components, or do you plan to implement custom components?

Custom components can provide very specific and powerful functionality for your application, but they take additional resources to design, develop, and test. For more information, see Developing Custom Notification Services Components.

What volume of notifications do you expect to deliver, for both base times and peak times? How important is high availability?

Notification Services supports scale-up, scale-out, and failover clustering hardware configurations. Knowing the notification volume and availability requirements will help you choose a hardware configuration. For more information, see Planning a Notification Services System.

What technologies do you plan to use to implement your subscription management interface?

You can implement your subscription management interface in managed code using the Microsoft .NET Framework and any of the languages it supports or you can submit basic subscriber and subscription data using Notification Services views. Managed code interfaces can directly access the Notification Services classes, while unmanaged applications must use COM interop and are limited to basic actions, not condition actions.

You can add subscriber and subscriber device data using Notification Services views. If your application uses event-driven subscriptions that support only basic actions, you can also add subscription data using these views.

Determining which implementation to use helps you determine what software you must install on each server, and can help you plan better for scale-out and failover.

For more information, see Developing Subscription Management Interfaces.

Do you need to integrate your Notification Services application with external databases or third-party applications?

Notification Services can obtain data from and deliver notifications to other systems. This integration typically happens through event providers and delivery protocols. Your applications can also query external databases to obtain event, subscription, or other data.

Integration requirements can affect many aspects of your Notification Services application, such as system performance, data formatting options, and notification delivery.

For more information, see Notification Services and Other Technologies.