Types of Subscription Management Interfaces


The two main types of SMIs are

  • SMIs that allow users to create and manipulate their own subscriptions

  • SMIs that allow administrators to manage all the subscribers and subscriptions in the whole system

The same SMI can technically be used for both user and administrator functions, but generally the operations supported in each case are different enough that combining the two leads to a clumsy interface. In this chapter, we focus on SMIs for users.

The API and development techniques described in this chapter apply to both kinds of SMIs. The main difference between the two SMI types is the scope of the subscriber and subscription information they present. User SMIs generally require a user to log in and then show only the subscriber and subscription information that pertains to that user. Typically, a user cannot view or modify the subscriptions belonging to any other user. Administrator SMIs present a view of the subscribers and subscriptions in the whole system. Administrators can manipulate any user's information. Administrator SMIs may also offer reporting and monitoring capabilities over all the subscriber and subscription information. Based on the material presented in this chapter and the administration and reporting capabilities of SQL-NS presented in Chapter 14, "Administering a SQL-NS Instance," you should be able to build an administrator SMI for your application, if one is required.

Tip

In practice, almost all applications have a user SMI, but only a few have an official administrator SMI. In many cases, administrative functions that relate to subscriber and subscription information are performed with ad-hoc tools.


Architecture of Subscription Management Interfaces

Many business applications follow the three-tier model shown in Figure 7.1.

Figure 7.1. The three-tier model for business applications.


This model separates the three aspects of a business application into distinct tiers, or layers:

  • The user-interface layer implements the visual controls that users interact with.

  • The logic layer implements the business rules, policies, and transaction semantics of the application.

  • The data layer provides persistent storage and querying capabilities for the application's data.

In this model, the layers communicate with each other over well-defined interfaces. This modular approach allows layers to be changed or replaced independently of one another.

For example, if the business rules of the application changed, the user interface would not have to be rebuilt. Similarly, building an alternative user interface (perhaps for a different target audience) would not require the business logic or database schema of the application to change.

It's a good idea to follow this same three-tier model when designing an SMI for a SQL-NS notification application. Figure 7.2 shows the how the elements of an SMI map to the three tiers:

Figure 7.2. A Subscription Management Interface as a three-tier application.


The user-interface layer presents visual controls by which users manipulate their subscriptions, and the data layer provides storage for the subscriber and subscription data. However, the need for the logic layer is sometimes less apparent.

To see why the logic layer is needed, let's recap what we did in the two preceding chapters. We implemented a set of subscription classes for the music store application, each of which represents a different kind of subscription. We defined the data schema for these subscription classes and the logic used to match subscriptions with events. But we didn't implement any business rules or policies around these subscription classes. Business rules and policies are outside the scope of SQL-NS and therefore are not implemented in the ADF. In a typical application, the rules and policies might specify restrictions on who can create subscriptions or the number of subscriptions that each user may have. For example, a business rule in your application might say that only "Premier Customers" can have scheduled subscriptions or that each user can have at most five subscriptions unless they pay a monthly fee. The rules and policies you implement are specific to your application. Whatever they are, they should be implemented in the logic layer of your SMI.

The data layer shown in Figure 7.2 includes the SQL-NS instance and application database objects. As we saw in Chapter 4, "Working with SQL-NS Instances," and Chapter 5, "Designing and Prototyping an Application," the subscriber information is stored in tables in the instance schema, and the subscriptions are stored in the application schema, in tables that the compiler creates for each subscription class. It's important to note that SQL-NS stores only the subscriber and subscription information it needs to perform its matching job. But, you may want to keep other information about the subscribers for different purposes. For example, your application may need to store a subscriber's billing address or privilege status. That type of information must be stored in your own database objects. The third cylinder shown in the data layer in Figure 7.2, labeled Non-SQL-NS Database Objects, represents this store of information outside the scope of the SQL-NS. In some applications, these objects may be in a separate database.

In this chapter, we build an SMI for the music store application prototyped in Chapter 5 and Chapter 6, "Completing the Application Prototype: Scheduled Subscriptions and Application State." Our SMI follows the architectural model shown in Figure 7.2.

Much of the material in this chapter focuses on the logic layer, which communicates with the SQL-NS databases through the SQL-NS Subscription Management API. This API represents subscriber and subscription information as objects that can be programmatically manipulated. The API persists any changes to the properties of these objects by writing the appropriate data to the SQL-NS subscriber and subscription tables. The API shields you from the internal structure of these tables and the mechanics of writing to them directly. Whereas applications typically use the SQL-NS Subscription Management API to create, update, and delete subscriber and subscription information stored in the SQL-NS tables, the standard database access APIs (such as SqlClient or ADO.NET) are used to manage any other associated data in non-SQL-NS tables.

In an SMI, the logic layer should communicate with the user interface layer through a well-defined interface. The exact nature of this interface depends on the operations that the application supports. In this chapter, we define the interfaces required by the music store application and then implement the code that carries out the operations.

Note

This chapter does not go into much detail about the building of the user interface itself. We'll look at the code for a sample user interface that uses the logic layer we develop in this chapter, but there isn't much coverage of the visual parts of the user interface. The parts of the user interface code that illustrate how the user interface connects to the logic layer are discussed in more detail. The reason for this is simple: The focus of this chapter is the SQL-NS Subscription Management API. User interface development is a topic unto itself and to go into a lot of detail about that here would be a significant diversion from the SQL-NS topics that this chapter teaches.





Microsoft SQL Server 2005 Notification Services
Microsoft SQL Server 2005 Notification Services
ISBN: 0672327791
EAN: 2147483647
Year: 2006
Pages: 166
Authors: Shyam Pather

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net