Banking

Get IT Done: Give notice to your users with Notification Services

Find out how the SQL Server add-on called Notification Services can deliver custom notifications to your users.


Last week I was having dinner with a friend and my friend received a page through his cell phone. I expected the page to be from his wife, but instead it was a score update from a baseball game. My friend explained to me that one of the big sports Web sites had a service where you could pay a subscription fee and you would be notified every time that a score changed. As the night went on, my mind began to wonder about how many other business practices could benefit from such technology. As it turns out, Microsoft makes a SQL Server add-on called Notification Services that can do exactly that—deliver custom notifications to your users.

What is Notification Services?
Notification Services is an add-on designed to deliver dynamic notifications to just about any device. For example, suppose that you had just purchased a stock and you wanted to know when the stock hit $65 per share so that you could sell. You could create a notification service application that would watch the stocks and send you an alert when the specified stock hit the requested price.

There are lots of Web sites and services that will notify you when a stock’s price changes. However, there are a couple of things that make Notification Services unique. For starters, you aren’t just limited to e-mail notifications. Notifications can be sent via e-mail or instant message, but they can also be sent to a pager, cell phone, Pocket PC, or to just about any other mobile device.

The other thing that makes this service unique is that it isn’t just limited to sending out information about the stock market. The notification service is actually a development package that allows you to code your own applications. You can send notifications about anything. For example, if you owned a small Web-based business, you might write a notification service application to inform you whenever a sale comes for collaboration. Or, as another example, members of a team could each be notified when someone on the team makes an update to a group project.

The best part is that Notification Services applications are easy to build and to integrate into your existing applications. This is because the applications are based on XML and Transact SQL. This means that anyone who is familiar with Visual Studio .NET and the .NET Framework could quickly build a Notification Services application.

How does it work?
A simplified explanation of Notification Services is that a person requests a subscription from an application. This subscription is a request to be notified when some condition becomes true. As the application runs, various events occur. The application collects these events and makes them available to Notification Services. Notification Services then uses Transact SQL to match subscriptions to events. Whenever a match is found, Notification Services generates a notification. The notification is then formatted and sent to a delivery service.

That’s the simplified version of how Notification Services works. If you’re interested in a more technical explanation, here it is: The Notification Services API allows for subscription management objects. Subscription management objects allow you to create your own subscription management applications. Applications built on subscription management objects store both subscriber and subscription information in SQL databases.

The next piece of the puzzle is designing your application in a way that generates meaningful events. This is a two-step process. Your application must be designed in a way that generates events in XML format. When an event occurs, the application must write the event to an XML file and place the file in a designated directory on the server. The file-system-watcher event provider monitors this directory for changes. If the file-system-monitor event provider detects that a new XML file has been added to the directory, it reads the file’s contents and then uses the information found in the XML file to make an entry into the application’s SQL database. In case you’re wondering, the file-system-event provider can either be run by Notification Services' event provider host component, or it can be run independently.

When an event has been added to the SQL database, Notification Services' generator component matches subscriptions to events and generates notifications if applicable. To preserve system resources, the generator component doesn’t run constantly, but rather is scheduled. When a developer codes a Notification Services application, the developer decides how frequently the application should check for events.

Some applications, such as one that would check stock prices, would require the generator to run very frequently. After all, stock prices can change every couple of minutes. On the other hand, an application that notifies team members if a shared document has been updated may only need to run the generator once an hour.

The generator component has another task as well. The generator is responsible for evaluating the transact SQL queries that were built into the application. This is what makes it possible for the generator to compare events to subscription data. It’s up to the developer to build this logic into an application, though. The developer must also provide the generator component with the text of the messages that will be generated when the generator finds a match.

The last step in the process occurs when the generator hands the notification off to the distributor component. The distributor component receives the notification and formats the text into something that is a little easier to read. This is done by using extensible style sheet language transformations (XSLT) or some other content formatting mechanism. Once the distributor finishes formatting the notification text, the notification is delivered, usually using SMTP.

When you build a Notification Services application, the application actually runs on the server as a service. The service name will be NS$application_name. Under normal circumstances, applications that you develop will use three processor threads. The event provider host uses one thread, the generator uses another, and the distributor uses a third thread.

Choosing your Notification Services version
Before you can download Notification Services, you need to figure out whether you need the Standard Edition or the Enterprise Edition. The main difference between the two versions is scalability. The Standard Edition is designed for small- to medium-size organizations. The idea behind this version is that the SQL database components run on the same server as Notification Services.

The Enterprise Edition allows Notification Services to run in a more distributed nature. Not only does the Enterprise Edition allow you to run Notification Services on a different server than your databases, but you can even run various components of the notification service on different systems. For example, the event provider, notification services generator, and a distributor component may all be run on different servers. This allows each server to focus on a specific task, thus providing the maximum level of performance for your notification application.

There are also some extra features that the Enterprise Edition has that the Standard Edition doesn’t. Some of the Standard Edition’s features have also been enhanced for the Enterprise Edition. One such feature is the ThreadPoolSize. As you probably know, a thread is an individual unit of execution, and Windows applications are made up of one or more threads. In the Standard Edition, the ThreadPoolSize limits notification service applications to using three threads simultaneously. This prevents an application from overburdening a server by executing too many threads simultaneously. In the Enterprise Edition, though, this limitation is removed and you are granted an unlimited ThreadPoolSize.

Another feature found in the Enterprise Edition that isn’t found in the Standard Edition is the BatchSize parameter. The BatchSize parameter allows an application to divide a workload into multiple batches. This allows applications to take advantage of parallel processing. Most of the time, the more that an application is able to rely on parallel processing, the faster and more efficiently the application will run.

In the Standard Edition, a single execution of a notification rule generates one batch of notifications. In the Enterprise Edition, though, when a notification rule is executed, the results can be divided into multiple batches instead of a single batch. Each of the multiple batches is smaller than a single batch would be, and the multiple batches may be processed simultaneously.

For example, suppose that you have a notification rule set up that generates two million notification messages. In the Standard Edition, all two million notifications would be lumped into a single batch for processing. If the same application were recoded to take advantage of the BatchSize parameter, though, then the application would still generate two million notifications. The difference is that rather than producing a single batch containing all two million notifications, the software might produce four batches of five hundred thousand notifications instead.

In this example, both systems are dealing with two million notifications, but the Enterprise Edition will be faster because the four batches can be run at the same time. Obviously, a system can process half a million requests much more quickly than it could process two million requests. If each of the four batches processes simultaneously, then the Enterprise Edition will complete the task 75 percent faster than the Standard Edition would.

In actuality, though, this isn’t a fair comparison. The reality is that the Enterprise Edition is much faster than the above example would lead you to believe because of the way that it makes use of multicasting. Suppose for a moment that in my earlier example the same notification message was being sent to all two million people. If this were done using the Standard Edition, then Notification Services would generate a copy of the message and send the message to the first user on the list. Once the message had been sent, the notification service would generate the message again and send it to the second person on the list. The point is that if the message has to be sent two million times, then the notification service will have to generate the message two million times.

The Enterprise Edition works differently though. Instead of generating the message separately for each recipient, the Enterprise Edition generates the message once and then sends that one copy to every designated recipient. Depending on the size and complexity of the message, this could reduce the processing overhead by more than 50 percent.

Now imagine that an application has been coded to take advantage of the unlimited ThreadPoolSize, uses multiple batches, and takes advantage of multicast delivery. The actual speed difference between the Standard Edition and the Enterprise Edition would depend greatly on the application type, the number of notifications, and the uniqueness of notifications. However, if the application deals with large numbers of notifications with lots of uniqueness, then the speed difference between the Standard Edition and the Enterprise Edition could be staggering.

Acquiring Notification Services
Prior to installing Notification Services, you need to make sure that the prerequisites are installed. Obviously, you must have SQL Server installed. If you are using the Standard Edition, SQL server must exist on the same machine where you are installing Notification Services. If you are installing the Enterprise Edition, SQL Server doesn’t necessarily have to run on the same server as Notification Services, but Notification Services do have to have access to a server that’s running SQL server.

The other software requirement is Visual Studio .NET. Remember that Notification Services is not a canned application, but rather a development tool. To develop applications that use Notification Services, you must have the .NET Framework (version 1.0.3705 or higher) installed. The .NET Framework is included with Visual Studio .NET.

The actual hardware and software requirements differ depending on whether you are developing an application or deploying an application that you have already built. If you are planning on developing an application, then Microsoft recommends that the development system have at least a 733-MHz Pentium III processor, 256 MB of RAM, and a GB of free disk space. The system must be running Windows 2000 Server, Windows 2000 Professional, or Windows XP Professional. You’ll also need Visual Studio .NET and SQL Server 2000 (Standard, Enterprise, or Developer Edition) running Service Pack 2 or higher.

To deploy an application that you have already developed, Microsoft recommends a server with at least a 733-MHz Pentium III processor and a GB of free hard disk space. The server must be running Windows 2000 Server, Advanced Server, or Datacenter Server. The Server must also have either the Enterprise or the Standard Edition of SQL Server 2000 and must have the .NET Framework installed.

You can download Notification Services from Microsoft’s SQL Server Web site. Both the Standard Edition and the Enterprise Edition are just under 8 MB in size. Before installing the Notification Services, you must keep in mind that any client that will be receiving notifications must have a SQL Server client access license. You can find a full description of the licensing requirements on Microsoft’s Licensing FAQ page, which discusses the 120-day trial version and the full version, but from the looks of the Downloads page, it appears that Microsoft has decided to make Notification Services a free add-on for SQL Server.

Editor's Picks

Free Newsletters, In your Inbox