What Has the SQL-NS Platform Provided?
In its final form, the the notification application is a database application coordinated by a Windows Service. To build the application, we had to write a relatively small amount of code. In fact, all we provided were the schemas for events, subscriptions, and notifications; the matching logic; and component configuration. From this, SQL-NS constructed the database application, including the tables, views, and stored procedures, for us.
In the previous section, we examined the parts of the database that resulted from the information specified in the ADF. We did not look into the multitude of other supporting tables, views, stored procedures, and functions required by the running application. These include code that maintains state about the application and enables it to recover gracefully after an unplanned shutdown, support for garbage collection of old event and notification data that has been completely processed, and several reporting and debugging utilities that can provide insight into what the running application is actually doing. All these were created for us, and we do not have to understand how they are implemented.
Many other benefits of building this application on SQL-NS have not been visible because we've run the application on such a small scale. But in fact, the application as it stands will support large volumes of events and subscriptions. (The exact number depends on the hardware you're using, but even on a modest developer system, it's possible to run applications with tens of thousands of events and subscriptions.)
Apart from the supported data volume, another aspect of the application that has not been visible because of the limited way in which we've used it is its manageability and reporting capabilities. For example, using simple SQL-NS tools, we could disable certain components of the application while leaving others running. This would allow us to perform incremental hardware and software maintenance without a total shutdown of the system. We could also obtain reports about the exact numbers of events and subscriptions going through the system. Chapter 14, "Administering Notification Applications," examines how to do these tasks, but even in this simple application, these capabilities are present because of what the SQL-NS platform has provided.
Furthermore, the application can be maintained and extended easily. If we wanted to, say, add a new type of event or a new subscription class, all we would have to do is add the necessary schema and logic to the ADF and then run SQL-NS tools to update the application (Chapter 5 introduces the tools and techniques for doing this). Updating the application would automatically modify existing database entities and create the new ones necessary to support the extensions. If we were building the application from scratch, this type of extension would likely be much more difficult.
If you were building the application from scratch, you would also have to do vast amounts of testing to ensure the reliability and security of the execution engine. Using SQL-NS, you can be sure that the execution engine has been designed with reliability and security in mind, and has already gone through rigorous testing in these areas.
In summary, although building just the core functionality of the application from scratch might not take that much longer than it does with SQL-NS, all the supporting features that make the application truly rich would be time consuming to build and difficult to get just right. SQL-NS provides these capabilities for free. Using SQL-NS reduces the time to market for your application and increases its reliability, security, and scalability.
Extending the Stock Application
Although the core of the application built here looks much like it would if this were a real application, its inputs and outputs do not. We have been reading events from hard-coded event files, entering subscriptions through administrative scripts, and looking at notification output through text files.
To make this application real, we would have to add a real event provider that read from a real event source. We would build a full subscription management interface to allow users to manage their subscriptions, and we would add support for delivery to real devices. Later chapters show how to do all these tasks.
Apart from input and output pieces, there is work we would do on the core of the application to make it more real. One limitation of the way the application works today is that it stores no state. So, subscribers get notified of every stock price change that is above the price target value they specified in their subscription. If I had a subscription for XYZ stock with a price target of $50, I'd get notified when the stock hit $51, then again if it fluctuated to $51.25, again if it went back down to $51, and so on. For any user, this flood of notifications would quickly become annoying.
To deal with this, the application could store state about the last price I was notified of. It could then temporarily suspend notifications to me until the price went significantly above this value so that I would not be bothered by intermediate fluctuations. Maintaining state is a core part of the SQL-NS application model, and Chapter 6 covers this in more detail.
Also, all the subscriptions right now are event triggered. That is, they fire in response to an incoming event. We could also support scheduled subscriptions: subscriptions that fire at a particular time of day. This would allow me, for example, to enter a subscription that said, "Notify me of the price of stock S at 5:00 p.m. every weekday."
This type of subscription does not fire in response to any given stock price change event. Rather, stock price events come in continuously during the day, and the application would have to keep track of the latest price for XYZ. At 5:00 p.m., it would send me a notification message containing the latest price. This type of subscription is also supported directly in the SQL-NS application model, and in Chapter 6, you'll see how to implement it.