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 for the stock application, it created database objects 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 objects and the Windows Service, are the key components of the running application. This section examines both to illustrate how the application really works.
The Database
Connect the Object Explorer in Management Studio to your SQL Server and expand the Databases node. You should see a new database called StockBroker (recall that this is the database name specified in the <Database> elements in the ICF and ADF). The SQL-NS compiler created this database when it compiled the ICF and placed database objects associated with the instance and application in it.
The instance database objects are created in a schema called NSInstance (this was the name specified in the <SchemaName> element in the ICF). If you expand the StockBroker database and look at the list of tables, views, and stored procedures, you’ll see several objects prefaced with the NSInstance schema name. For now, we’ll ignore these instance database objects and focus on the application database objects instead. We’ll revisit the instance database objects in Chapter 4.
In the list of tables, views, and stored procedures in the StockBroker database, many objects are qualified with the StockWatcher schema name. These are all the application database objects the compiler created for our StockWatcher application. Many of these are for internal use by the SQL-NS engine, so we won’t explore them here. But I do want to show you a few of them to give you an idea of what the compiler did with the information in the ADF.
Look for a table called StockWatcher.NSStockPriceChangeEvents. If you look 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 StockWatcher.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 a StockWatcher.NSStockAlertNotifications table that stores StockAlert notification data.
The Views node under the database in the Object Explorer shows the list of views the compiler created. In this list, you’ll find all the views used to insert data in the Test.sql script we ran earlier.
Also, look at the StockWatcher.NSFireDeveloperDefined1 stored procedure. In Object Explorer, stored procedures are located under the Programmability node beneath the database, in the Stored Procedures subnode. To see the definition of the StockWatcher. NSFireDeveloperDefined1 stored procedure, right-click it, select Script Stored Procedure As, CREATE To, and then New Query Editor Window in the series of context menus. As the definition shows, StockWatcher.NSFireDeveloperDefined1 wraps the text of the <Action> element in the match rule declaration in the ADF. Look for a comment that says /** APPLICATION DEFINED RULE STARTS HERE **/. Immediately after this comment, you’ll see the rule text we supplied in the ADF. When the SQL-NS engine needs to invoke this matching logic, it executes this stored procedure.
Spend some time looking at other objects in the database to get a feel for what’s there. Don’t be alarmed by the number of objects you see—you’ll only ever have to deal with a small number of these as you build SQL-NS applications. The rest are there to support the rich features that SQL-NS provides.
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 this configuration information, the service instantiates the appropriate execution components and starts them running.
Our application had a single generator, configured with a quantum duration of 15 seconds. On startup, the Windows service instantiated a generator component that checks the database for new batches of events every 15 seconds. When our test script wrote events to the database, the generator processed them by executing the stored procedures that contain 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 (again, every 15 seconds, as specified by the distributor’s quantum duration) checks the database for new notifications to format and deliver. When the evaluation of the matching logic by the generator 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.