Event Provider Concepts

This section describes some of the key concepts related to using and building event providers. These concepts form the basis for the material covered in the rest of this chapter.

Event Providers and Event Sources

SQL-NS applications typically deal with two kinds of event sources:

• Active event sources that push events out to interested parties

• Passive event sources from which interested parties pull events

For example, a traffic alerting system that broadcasts incident reports to listeners is an active event source. In contrast, a web service that clients have to poll to obtain stock market data is a passive event source.

Note

Active event sources may actually be implemented as notification applications. The output (notifications) of one notification application may well be the input (events) of another.

Both types of event sources interface with SQL-NS applications via event providers, but event providers behave differently depending on whether the event source is active or passive.

An event provider working with an active event source typically registers itself with the event source as a listener and then waits to receive events. When an event arrives from the event source, the event provider submits the corresponding event data to the SQL-NS application, as illustrated in Figure 8.1.

Figure 8.1. An event provider working with an active event source.

An event provider that works with a passive event source usually polls that event source periodically, looking for new events. If it finds new events, the event provider submits the appropriate event data to the SQL-NS application, as shown in Figure 8.2. Some of the event provider's polling attempts may not yield any events. In these cases, it simply waits until the next polling interval and then looks again.

Figure 8.2. An event provider working with a passive event source.

Event Batches

When an event provider submits events to a SQL-NS application, it always groups them into units called event batches. Until now, we've mostly been considering the processing of individual events, but the batch concept becomes important when implementing event providers. An event batch represents a group of events that logically go together. SQL-NS treats a batch of events as an atomic unit: Either all the events in the batch are processed, or none of the events in the batch are processed.

Note

Processing events in batches rather than one at a time gives a performance advantage. The overhead involved in rule execution is incurred only once for the whole batch, instead of once per event. Batching does introduce latency because the entire batch must be submitted before its first event is processed. However, in most cases, the efficiency gains from batching lead to higher overall throughput than one at a time evaluation.

Earlier, when you looked at the SQL-NS application database objects, you saw that for each event class, the SQL-NS compiler created an events table named NS<EventClass>Events. You may also have noticed (although it wasn't explicitly pointed out) that there is also a table named NS<EventClass>EventBatches. As its name suggests, this table is used to track information about event batches. Each row in the table represents a single event batch and has columns for the event batch ID (a unique identifier for the event batch), the ID of the event provider that submitted the batch, as well as the times that the collection of the event batch started and ended. The events table relates to the event batches table via the EventBatchId column, which contains the ID of the batch that each event belongs to. Figure 8.3 illustrates this relationship.

Figure 8.3. The event batches and events tables.

Each of the SQL-NS built-in event providers groups events into batches in different (although well-defined) ways. When building your own event providers, you can define any batching behavior you choose.

Event Provider Security

Because event providers connect between SQL-NS applications and the outside world, it's important to make sure that they are secure. Hackers must not be able to gain unauthorized access to the internal data of a SQL-NS application by means of an event provider and, perhaps more importantly, should not be able to compromise an event source by means of an event provider.

This section describes some of the facilities that SQL-NS offers for securing event providers. Note that these are just mechanisms. It's up to you to use them appropriately to secure the event providers in your applications.

Database Roles

As you've already seen, SQL-NS database security is role based. When the instance and application database objects are created, SQL-NS creates several database roles, each of which corresponds to a specific function of a running SQL-NS instance. It then sets the permissions on the various database objects so that only members of the appropriate roles can access them. For example, the permissions on the database objects involved in subscription management are set so that only members of the subscription management role are allowed access. You control the access that accounts have to the instance and application database objects by selectively granting them membership in the various SQL-NS roles.

NSEventProvider is the SQL-NS role for all operations related to event submission. Members of this role have access to all the database objects involved in event submission, including the events and event batches tables, as well as several internal tables, views, and stored procedures used by the SQL-NS engine.

If your event provider is hosted in the SQL-NS engine, it will run under the engine's account. If your event provider is standalone, it will most likely run under the account that started the standalone process. Event providers can connect to the SQL-NS database via either Windows Authentication (using the credentials of the Windows account under which they run) or SQL Server Authentication (using a SQL username and password). Regardless of which authentication scheme is used, the account with which the event provider connects to the database needs to be a member of the NSEventProvider role. You will need to grant membership in this role to the appropriate accounts when the application is deployed.

By using a low-privileged account to run your event provider and granting it only the permissions it needs (through role membership), you minimize the damage that a hacker could do if your event provider is compromised. Because membership in NSEventProvider does not provide access beyond the objects involved in event submission, the access that a hacker may obtain by hijacking the event provider is limited to these objects.

In Chapter 4, "Working with SQL-NS Instances," we examined the grant_permissions.cmd script that adds the service account to the NSRunService role (see the "Granting Permissions" section of Chapter 4, p. 92). NSRunService can be thought of as a combination of several separate roles, typically required by components running in the SQL-NS engine. Using NSRunService is a convenience when you have several components running under a single account. Instead of granting that account membership in all the separate roles, you just grant it membership in NSRunService. NSEventProvider is included in the list of roles that NSRunService covers. As in previous chapters, the SQL-NS service account is granted membership in NSRunService, so we don't explicitly need to grant it membership in NSEventProvider for its hosted event providers to work.

Later in this chapter, we'll build and test several standalone event providers. Because these are not hosted in the Windows service, they don't run under the service account. In the development stage, you'll run these using your development account, which doesn't need to be granted membership in NSEventProvider because it is already a system administrator. If you deployed any of these standalone event providers in a real production environment, you would have to grant membership in the NSEventProvider role to the account with which they connect to the database.

Argument Encryption

As shown later in this chapter, when you configure a hosted event provider in the ADF (in a <HostedProvider> element), you provide a set of arguments that the engine later passes to the event provider when it starts. When you compile your application, the compiler stores these arguments in a table in the application's database.

In some cases, these arguments may contain sensitive information, such as usernames and passwords used to connect to event sources. Simply storing these in the database in plain-text may present a security risk. For this reason, SQL-NS provides argument encryption: a facility for encrypting the event provider arguments before the compiler stores them in the database. The SQL-NS engine stores the encryption key securely in the Registry and uses it to decrypt the arguments before passing them to the event provider. Using this mechanism, you can greatly reduce the chance that an unauthorized user looking at the contents of your database will be able to obtain any sensitive information stored in arguments.

To configure argument encryption, you use the <EncryptArguments> element of the ICF. This is a Boolean element, and its value indicates whether to encrypt arguments. In previous chapters, the ICFs we've used have not specified the <EncryptArguments> element, which is equivalent to specifying the element with a false value. In this chapter, we add the <EncryptArguments> element to the ICF and set its value to true. A fragment of the ICF showing the <EncryptArguments> element is shown in Listing 8.1.

Listing 8.1. The <EncryptArguments> Element of the ICF

 <NotificationServicesInstance>   ...   <EncryptArguments>true</EncryptArguments> </NotificationServicesInstance> 

Caution

You cannot change the value of the <EncryptArguments> element after the instance is created. The SQL-NS update tools return an error if they detect that the value of this element has been altered in the ICF when updating an instance. If you must change the value of <EncryptArguments>, you have to delete and then re-create the instance.

If you specify TRue for <EncryptArguments> in the ICF, you must provide an encryption key when you create, register, and update the instance. This key is used to encrypt and decrypt the arguments and is commonly referred to as the argument key. The argument key is used differently by the three operations:

• When creating an instance, the SQL-NS compiler uses the argument key to encrypt the arguments specified in the ADF and store them in the database.

• Registering an instance stores the argument key securely in the Registry so that the SQL-NS engine can obtain it when it needs to decrypt the arguments at runtime.

• When updating an instance, the SQL-NS compiler uses the argument key to first decrypt the arguments currently stored in the database (so that it can compare them to the values in the ADF to detect changes) and then encrypt any new or modified argument values that it writes back to the database.

The argument key can be any string you choose. Both sets of SQL-NS tools (the nscontrol commands and the graphical tools in Management Studio) provide mechanisms for you to specify the key value. In the next section, we'll look at how these are used (see "Changes to the Scripts for Argument Encryption," p. 240).

Note

Argument encryption applies to all arguments supplied in the ADF and ICF, not just those for event providers. Other places that arguments are used include the configuration of delivery channels and content formatters. We'll look at these in more detail in Chapters 9, "Content Formatters," and 10, "Delivery Protocols."

To view the argument key used to encrypt the arguments of a SQL-NS instance, you can use the nscontrol displayargumentkey command or view the Encryption tab of the instance's properties dialog box in Management Studio (right-click the instance in the Notification Services folder in the Object Explorer and choose Properties). The account used to view the argument key must be a member of the Administrators or Power Users groups; otherwise, access to the argument key will be denied.