Home > Articles

  • Print
  • + Share This
This chapter is from the book

What Has the SQL-NS Platform Provided?

In its final form, 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.

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 did 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 a SQL-NS Instance," 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 add a new type of event or a new subscription class, for instance, 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, "Designing and Prototyping an Application," 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 incremental update 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.

  • + Share This
  • 🔖 Save To Your Account