Specifying Other Parts of the Stock Application
The ADF defines the core of the application, but several other pieces are required to make it run. This section briefly describes those pieces as they pertain to the stock application.
SQL-NS has the concept of instances, in much the same way that SQL Server does. A SQL-NS instance is a single, named configuration of SQL-NS that can host one or more applications. Each instance is an independent entity that can be started, stopped, and configured on its own. In SQL-NS, an instance is defined by an Instance Configuration File (ICF). The ICF defines the list of applications in the instance (here, just one—the StockWatcher application) and the set of delivery channels that applications in the instance can use to send notifications.
This sample’s ICF creates a Notification Services instance called StockBroker. I’ve included the text of the ICF in Listing 3.10, but I will not go into an explanation of it here because most of the details are not relevant at this point. Chapter 4, "Working with SQL-NS Instances," covers the instance concepts and all the elements of the ICF in detail. If you have the Management Studio project for this sample open, you’ll find the ICF under the Miscellaneous node in the StockBroker project—the file name is InstanceConfiguration.xml.
Listing 3.10 The ICF That Defines the SQL-NS Instance That Hosts the Stock Application
<?xml version="1.0" encoding="utf-8"?> <NotificationServicesInstance xmlns:xsd=http://www.w3.org/2001/XMLSchemaxmlns:xsi=http://www.w3.org/2001/XMLSchema-instancexmlns="http://www.microsoft.com/MicrosoftNotificationServices/ConfigurationFileSchema"> <InstanceName>StockBroker</InstanceName> <ParameterDefaults> <Parameter> <Name>_SQLServer_</Name> <Value>... Your SQL Server Name ...</Value> </Parameter> <Parameter> <Name>_NSServer_</Name> <Value>%COMPUTERNAME%</Value> </Parameter> <Parameter> <Name>_InstanceBaseDirectoryPath_</Name> <Value>C:\SQL-NS\Samples\StockBroker</Value> </Parameter> </ParameterDefaults> <SqlServerSystem>%_SQLServer_%</SqlServerSystem> <Database> <DatabaseName>StockBroker</DatabaseName> <SchemaName>NSInstance</SchemaName> </Database> <Applications> <Application> <ApplicationName>StockWatcher</ApplicationName> <BaseDirectoryPath>%_InstanceBaseDirectoryPath_%\StockWatcher</BaseDirectoryPath> <ApplicationDefinitionFilePath>ApplicationDefinition.xml</ApplicationDefinitionFilePath> <Parameters> <Parameter> <Name>_NSServer_</Name> <Value>%_NSServer_%</Value> </Parameter> <Parameter> <Name>_ApplicationBaseDirectoryPath_</Name> <Value>%_InstanceBaseDirectoryPath_%\StockWatcher</Value> </Parameter> </Parameters> </Application> </Applications> <DeliveryChannels> <DeliveryChannel> <DeliveryChannelName>FileChannel</DeliveryChannelName> <ProtocolName>File</ProtocolName> <Arguments> <Argument> <Name>FileName</Name> <Value>%_InstanceBaseDirectoryPath_%\FileNotifications.txt</Value> </Argument> </Arguments> </DeliveryChannel> </DeliveryChannels> </NotificationServicesInstance>
As it does with the ADF, the SQL-NS compiler creates a set of database objects for the instance from the information provided in the ICF. The <Database> element in the ICF specifies where these objects go. In this case, you can see that they are deployed into the same StockBroker database as the application objects, but isolated in a different schema called NSInstance.
Notice that the ICF contains a reference to the ADF for each declared application. In Listing 3.10, the <Application> element that declares the StockWatcher application includes an <ApplicationDefinitionFilePath> element that provides the path to the ADF. At compile time, you pass just the ICF to the SQL-NS compiler. Based on the <ApplicationDefinitionFilePath> elements in the ICF, the compiler locates, loads, and compiles each application’s ADF.
Entering Event and Subscription Data
If this were a real application, it would use an event provider that would read and submit real stock data from one of many stock market data publishers. It would also have a subscription management interface by which users could enter subscriptions. Because the focus of this chapter is the core SQL-NS concepts, not the mechanics of reading from stock market data sources or implementing user interfaces for subscription management, we’ll use a simple test script to submit event and subscription data. The data submitted through this script will allow us to observe how the application and the SQL-NS platform work. Chapters 7 and 8 cover the building of subscription management interfaces and event providers in detail.
The test script that submits event and subscription data is included in the StockBroker Management Studio project. To open the script, expand the Queries node under the StockBroker project in Solution Explorer and select the Test.sql file. Do not run this file yet—the database objects it relies on don’t exist yet because we haven’t compiled the SQL-NS ICF and ADF. Just open the file to look at its contents for now.
The script first creates subscriber and subscriber device records for four test subscribers. The records are created by inserting rows into subscriber and subscriber device views in the instance schema in the StockBroker database. It then enters a subscription for each subscriber by inserting rows into the subscription class view in the StockWatcher application schema. Finally, it inserts a set of test events into the event class view. After compiling the application, we’ll run this script to test it.
Seeing the Final Notifications
After raw notification data is generated, it gets formatted and then delivered. In this sample, we’ll use the built-in XsltFormatter content formatter provided by SQL-NS that turns the raw notification into a readable message using an XSL transform. Although the XSLT formatter is used in the examples in the next several chapters, I’ll defer explaining the details of how it works until Chapter 9, "Content Formatters."
On the delivery side, this sample application uses another SQL-NS built-in component: the File Delivery Protocol. This component "delivers" the notifications to a file. You can then check the output of the application simply by opening this file. The subscriber device records created by the test script you examined in the previous section tell the SQL-NS distributor to route the formatted notifications for the test subscribers to the output file. In a real application, you’d probably use several delivery protocols that could send the notification messages via email or as text messages to cell phones, for example. Chapter 10 describes all the built-in SQL-NS delivery protocols and shows how you can build your own custom delivery protocol.