Examining the Parts of the Instance


In this section, we'll take a more in-depth look at the elements of the instance we created. If you're eager to get coding, you can skip this for now, but it's worth reading to solidify your understanding.

Instance Database Objects

The instance database objects are used to store subscriber data, information about the applications in the instance, the installed delivery protocols, the configured delivery channels, as well as common reference information needed by all applications in the instance. The following sections describe some of the key instance database objects.

Subscriber Data

SQL-NS applications are about providing notification services to subscribers. As you saw in Chapter 3, the subscriptions are stored as rows in tables. As you might expect, the data about the subscribers themselves is also stored in tables.

However, instead of subscriber data being stored in each application, it is stored at the instance level. This means that all applications within a single instance share a single set of subscribers. Each application maintains its own subscriptions, but the subscribers are common. The shared subscriber data includes the subscriber ID, enabled status, timestamps to track when the subscriber record was created and modified, and delivery device information.

Sharing subscriber data makes sense because applications grouped in a single instance are usually related, and the subscribers are likely to have subscriptions in more than one of those applications. Sharing the subscribers avoids duplication of data.

Two main tables in the instance schema relate to subscribers: NSSubscribers and NSSubscriberDevices. As you might expect from their names, the first table stores information about subscribers themselves, and the second stores information about the devices on which subscribers receive notifications. In Chapter 7, we'll examine subscribers and subscriber devices more closely, but for now, you should explore the structure of these tables in Management Studio. (The instructions in the "Examining the Database" section, p. 88, earlier in this chapter, explain how to view the instance database objects in the Object Explorer.)

Application Configuration

The instance's database contains the list of applications in the instance, as well as the enabled state of each. This allows the Windows service to properly manage the instance's applications. The application information is stored in the NSApplicationNames table in the instance schema. Execute the following query in a Management Studio query window to see the list of applications:

 USE MinimalMultiApplication SELECT * FROM [NSInstance].[NSApplicationNames] 


This should return two rows: one for each of the two skeleton applications in our sample instance.

Delivery Protocols and Delivery Channels

The instance's database also contains the list of installed delivery protocols that applications in the instance can use to send notifications. Delivery protocols are components that implement the required communication mechanisms to enable notification delivery to various network endpoints. For example, an SMTP delivery protocol component implements the message exchange and format defined by SMTP for sending email. Delivery protocol implementations are components that can plug into the SQL-NS framework. SQL-NS ships with some protocol implementations built in, but others can be developed and installed later. Because the list of installed protocols is kept in the instance, the protocols are available to all the applications in the instance.

In addition to the delivery protocols, the instance database also maintains the list of configured endpoints to which notifications can be sent. For example, it may list the SMTP servers in your network that are used for sending email notifications. The configuration information usually includes the name of the endpoint and authentication information used to negotiate a session with it. Each configured endpoint is called a delivery channel. Both delivery protocols and delivery channels are discussed in more detail in Chapter 10; for now, just note that the NSProtocols, NSDeliveryChannels, and NSDeliveryChannelArguments tables in the instance schema store configuration information about them.

Common Reference Information

The instance schema also contains some tables used by all applications for reference information. For example, tables store time zone information (NSTimeZones, NSTimeZoneNames, and NSTimeZoneDstOffsets) and another lists the supported locales (NSSubscriberLocales).

Application Database Objects

As we saw when we created the instance, the SQL-NS compiler creates a database schema for each application in the instance. This schema contains tables used to store the configuration information about the application, as well as the application's events, subscriptions, and notifications. We'll examine the contents of an application schema in detail in Chapter 5.

Instance Metadata

When the SQL-NS compiler creates the instance and application database objects, it also installs metadata about the instance in the SQL-NS system tables. This metadata is used by the SQL-NS tools to enumerate the instances on a server (the list of instances you see in the Object Explorer is obtained from the metadata tables). The SQL-NS metadata tables are in the msdb system database, in the NS90 schema. You should never add, remove, or alter the data in these tablesthey are intended for system use only.

You can view the instance metadata by executing the following query in a Management Studio query window:

 USE msdb SELECT * FROM [NS90].[NSInstances] 


This query will result in a row of data for each instance on your SQL server.

Because it's critical that the instance metadata maintains an accurate picture of the instances on a server, you should never attempt to remove an instance by dropping its database. If you do this, the metadata for the instance will remain, even though its database objects are gone. Instead, you should always delete instances by using the nscontrol delete command, or via Management Studio by right-clicking an instance in the Object Explorer and selecting Tasks, followed by Delete. Both tools will clean up the metadata appropriately, after the instance has been removed. See the "Cleaning Up the Instance" section (p. 112) near the end of this chapter for more information on removing a SQL-NS instance.

Tip

If you do accidentally remove a SQL-NS instance database, you can remove the associated metadata by running nscontrol delete. The command will display an error message indicating that the instance database could not be found, but it will also remove the instance's metadata if it is present. See the documentation for nscontrol delete in the SQL-NS Books Online for more details.

If you need to move a SQL-NS instance's database from one server to another, you can rebuild the metadata for the instance on the new server using the nscontrol repair command. For more information on nscontrol repair, see the SQL-NS Books Online.


Registry Keys

SQL-NS stores almost everything about an instance and its applications in the database. But, for the running components of the instance to get to that information, they have to be able to connect to the database: They need to know the database server name, and the SQL username and password to supply if SQL Server Authentication is used.

Obviously, this information can't be stored in the database (we'd have a chicken-and-egg problem if it was), so it's stored instead in a well-known place in the Registry. Given an instance name, SQL-NS components can look up the database connection information for the instance. Registering the instance using either nscontrol register or the Register Instance command in Management Studio places this information in the Registry. Note that if a SQL username and password are stored, they are encrypted.

The instance Registry keys are stored under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Services\NotificationServices\Instances. When you register an instance, SQL-NS creates a key in this Registry location, with the instance name. The database connection information is then stored as a set of values beneath this key. Figure 4.6 shows these Registry keys for the instance created in this chapter (viewed using the regedit tool).

Figure 4.6. The instance Registry keys shown in the Registry Editor.


Caution

You should never manually change the instance registration in the Registry. Instead, always use the nscontrol or Management Studio commands to manipulate the instance registration.


Multiple Side-By-Side Instances

SQL-NS allows several instances to exist side-by-side on a single computer. Logically, you can treat each instance as a separate installation of SQL-NS, although all instances on a single computer usually run off the same installed SQL-NS program files.

Each instance is independent of all other instances; instances can be administered separately and configured under different security accounts. Different instances on the same computer can even run different versions of SQL-NS. Whenever you do a SQL-NS operation, you always do it against some particular named instance.





Microsoft SQL Server 2005 Notification Services
Microsoft SQL Server 2005 Notification Services
ISBN: 0672327791
EAN: 2147483647
Year: 2006
Pages: 166
Authors: Shyam Pather

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net