SQL Server 2005 Notification Services

Are you using SQL Server 2000 Notification Services? Do you know what Notification Services is? This interesting SQL Server component can add a lot of value but has a low overall adoption level--there just aren't a lot of folks using it in production. However, I think that will change when SQL Server 2005 comes out in November. I spoke with Notification Services Development Lead Shyam Pather to get some insight about Notification Services 2005.

Notification Services is a framework for making rich but scalable event and subscription-matching applications. Developers use Notification Services to build alerting applications that generate and deliver alerts for events (e.g., an alert that tells a customer that an out-of-stock item is available for order). Typically, events generate notifications that match criteria from user-generated subscriptions. MSN Alerts uses Notification Services to generate several million notifications per day.

Notification Services' out-of-the-box delivery channels include HTTP, file delivery, and SMTP. A few independent software vendors (ISVs) offer adapters for Short Message Service (SMS) enabled devices and other delivery channels. MSN Alerts offers a service that lets you plug into the MSN messaging-server infrastructure from your Notification Services applications or you can build your own custom adapters for data sources and delivery channels.

The overall experience of developers who use Notification Services 2005 is greatly improved compared to development with Notification Services 2000. Development in Notification Services 2005 is more straightforward and supports incremental development; lets users define applications using statement auto-completion and syntax checking when editing XML documents; and includes full Management Studio integration, command-line support, and programmatic support through a managed API. Also, Notification Services applications are much more easily embeddable. A Notification Services application no longer requires a dedicated metadata database but can exist inside their dependent database using its own dedicated namespace. And you can embed Notification Services applications' processes in other processes. Also new in 2005, the product includes support for end-user rules, which let subscribers define the logic that determines when they get notified about an event. For example, in an application that deals with stock prices, one subscriber might request to be notified when a stock's value crosses a threshold, another when the price falls within a particular range of values. In Notification Services 2000, subscriptions have to follow predefined templates with logic defined by the application developer. The new structure lets applications go beyond traditional architecture, in which all rules are defined during application development, and users can adjust only parameters in their subscriptions.

As of last February, Notification Services is part of the Microsoft SQL Server Business Intelligence (BI) platform. When you look at Microsoft's three BI pillars--Integrate, Analyze, Report--you see that Notification Services is an important feature for the Reporting pillar. Now that Microsoft is marketing Notification Services as part of the BI family, I think customers will begin to understand the value Notification Services brings to SQL Server and the component will see a higher adoption rate when SQL Server 2005 hits the shelves. Beyond 2005, I think we'll see a strong integration between Notification Services and the BI Development Studio. My thanks to Pather for spending time providing insight about Notification Services; I encourage you to try it out in SQL Server 2005, read the documentation in SQL Server Books Online (BOL), and try the samples.