This chapter is from the book
This chapter is from the book
This chapter is from the book
Inside the Running Application
When the SQL-NS compiler processed the ADF, it created a database structure from the information in it. When we registered the instance, SQL-NS installed a Windows Service to host its execution engine. These two pieces, the database and the Windows Service, make up the running application. This section examines both to illustrate how the application really works.
The Database
Connect to your SQL Server using Query Analyzer (or any other tool that lets you browse database objects):
-
Open Query Analyzer (from your Start menu, choose Programs, Microsoft SQL Server, Query Analyzer).
-
Log in to your SQL Server.
-
If the Object Browser (the tree view showing all the database objects on your SQL Server) is not showing, press F8 to make it visible.
In the Object Browser, observe that two new databases have been added: Chapter03NSMain and Chapter03Stock. The first is referred to as the instance database; it stores all the information shared among applications in the instance. SQL-NS always names the instance database <InstanceName>NSMain. Chapter03Stock is the application database and contains all the tables, views, stored procedures, and functions required to run the stock application. SQL-NS names application databases <InstanceName><ApplicationName>. So, for every instance, the SQL-NS compiler creates an instance database and one application database for each application within it.
For now, we'll ignore the instance database and focus on the application database (Chapter03Stock). If you expand the Chapter03Stock node in the Object Browser, you'll see many tables, stored procedures, and views (under the "User Tables", "Stored Procedures", and "Views" sub-nodes respectively). Many of these are just for internal use by the SQL-NS engine, so we won't cover them here. But I do want to show you a handful of these to give you an idea of what the compiler created from the information in the ADF.
Look for a table in the Chapter03Stock database called NSStockPriceChangeEvents. Expand the NSStock PriceChangeEvents node in the Object Browser tree and then expand the "Columns" sub-node beneath it. Looking at the columns in this table, you'll see that all the fields from the StockPriceChange event class declaration have become columns in this table. SQL-NS has also added its own extra columns that it uses for internal tracking. This table is used to store events and was created by the compiler from the event class definition. Similarly, you'll see a table called NSStockPriceHitsTargetSubscriptions that matches the schema of the StockPriceHitsTarget subscription class and is used to store subscriptions of that class. As you might expect, there is also an NSStockAlertNotifications table that stores StockAlert notification data.
Close the "User Tables" node under Chapter03Stock in the Object Explorer tree and expand the "Stored Procedures" node. Look at the NSFire1 stored procedure. You can right-click on it in the tree and choose Edit to see the text. This stored procedure contains some SQL-NS generated code but also contains the text of the <Action> element in your match rule declaration in the ADF. Look for a comment that says /** APPLICATION DEFINED RULE STARTS HERE **/. Immediately after this comment, you'll see your rule text. SQL-NS has compiled your rule into this stored procedure. The code before and after the rule text sets up and tears down the internal SQL-NS state required to run your rule. What this wrapper code actually does is not important to understand; it's all related to SQL-NS internals, which, as an application developer, you are insulated from.
The Windows Service
In addition to the tables and stored procedures just examined, the SQL-NS compiler also stores the component configuration information from the ADF in the database. On startup, the Windows Service connects to the database and reads this configuration. This includes the number and type of event providers, as well as the configuration of the generator and distributors. Using the configuration information, the service instantiates the appropriate execution components and starts them running.
In the case of our stock application, we had only one event provider: the FileSystemWatcher. Based on this configuration information, the service created an instance of the FileSystemWatcher component and passed it the startup parameters specified in the ADF. This event provider monitored the filesystem directory we specified, and when we copied an event data file into this directory, it read it and submitted the data as events. These events ended up in the events table in the database.
Our application had a single generator with the default configuration. On startup, the Windows Service instantiated a generator component that periodically checked the database for new batches of events. When our FileSystemWatcher event provider wrote events to the database, the generator processed them by executing the stored procedures that contained our rule logic. This resulted in notification data stored in the notification tables.
The single distributor we configured in our ADF was also represented by a running component in the Windows Service, instantiated on startup. This component periodically checked the database for new notifications to format and deliver. When the generator firing caused the notifications to be written to the notifications table, the distributor read them, passed them through the content formatter we specified, and then wrote them to the output file using the file delivery protocol.
Figure 3.7 shows the Windows Service and its interactions with the database.
)
Figure 3.7 The running Windows Service interacting with the database.