| Now that you've created the model music store database, the stage is set for designing and building the notification application itself. In this section, we'll complete the first development phase: initial design. When designing any notification application, I find it helpful to answer the following seven questions about the application: What does the application do? Who are the target users of the application? What events trigger subscription matching? What kinds of subscriptions can users enter? Where do the events come from? What kinds of notifications does the application send? What state information does the application need to keep as it runs?
Clear answers to these seven questions capture the high-level design of your application. After you answer these questions, you can move on to specifying the implementation details that relate to each one. Let's answer these seven questions for the notification application we're going to build in this chapter. What does the application do?This application is a notification service for an online music store. The store provides a selection of digital music that customers can download for a fee. The notification service allows customers to request and receive notifications about new music added to the store's inventory that is of interest to them. Who are the target users of the application?The application is targeted primarily at the customers of the music store. Customers wanting to receive timely notifications of new music available for purchase can set up subscriptions with the notification service. Instead of having to browse the music store repeatedly to look for new songs that have become available, the subscribers will be notified when new music that matches their stated criteria of interest is added. What events trigger subscription matching?The events of interest are new songs being added to the store. When a new song is added, notifications should be generated for subscriptions that the song matches. What kinds of subscriptions can users enter?Most subscribers will not want to be notified about every new song added to the store. Rather, they will want to specify which ones are of interest to them and receive notifications about only those. The application provides subscribers with two ways to specify their music notification preferences: They can subscribe by artist or by genre. In other words, they can choose to receive notifications about all songs by a particular artist, or all songs of a particular genre. Each subscription allows the subscriber to specify one artist or one genre, but each subscriber may have several subscriptions of each type. The subscriptions by artist are event-triggered. In other words, as soon as an event arrives (indicating that a new song has been added), the application evaluates the subscriptions by artist to see whether the song matches. The notifications generated for these subscriptions are relatively immediate with respect to the arrival of the event. In contrast, the subscriptions by genre are scheduled. Each subscription specifies a recurring schedule (for example, every week day at 9 a.m.) that will tell the application when it should be evaluated. Rather than evaluating each subscription every time a new song is added, the application evaluates the genre subscriptions at the times the subscriber has specified, against a history of songs added since the last time the subscription was evaluated. Depending on the evaluation time specified in a subscription, there may be a long delay between the arrival of a matching event and the generation of the corresponding notification. The SQL-NS platform has built-in support for scheduled subscriptions. Very little work is required of developers to support them in SQL-NS applications. As we prototype the application, we'll take a detailed look at this powerful platform feature.
Note The reason that we choose to evaluate the two types of subscriptions differently has to do with selectivity, or the expected frequency of matching events. Consider a subscription by artist: Only songs by the particular artist specified in the subscription would result in a match. You would not expect many songs by any single artist to be added frequently. In contrast, subscriptions by genre are much less selective. Songs by many different artists may match a genre-based subscription. Therefore, matching events would occur much more frequently than in the case of subscriptions by artist. If we made the subscriptions by genre event triggered, the number of notifications generated would overwhelm the subscriber. Subscribers would be bombarded with notifications throughout the dayan unpleasant user experience, to say the least. Making the subscriptions by genre scheduled allows the application to evaluate them against a whole set of events that may have accumulated and generate a set of notifications at once. The application may even group the resulting notifications and send them to the subscriber in a single, convenient message.
Where do the events come from?Events that indicate that new songs have been added originate from the music store catalog itself. When a new song is added to the catalog, data about the song will be submitted to the notification application. What kinds of notifications does the application send?The application sends only one kind of notification: a message indicating that new songs have been added. If several such messages are going to be sent to the same subscriber (for example, if a batch of songs was added, several of which match the subscriber's subscriptions), the application combines those separate messages into a single digest message that consolidates the information from each of the separate messages. What state information does the application need to keep as it runs?Because the subscriptions by genre are scheduled subscriptions, they may be evaluated well after the submission of the event data against which they need to operate. Therefore, the application must keep a history of the events it sees and make this available to the matching logic of the scheduled subscriptions. Each scheduled subscription should be evaluated only against the songs added since the last time it was evaluated. Because the event history contains all songs added, even those against which subscriptions have already been evaluated, the application needs to keep a log of the last evaluation time of each scheduled subscription. It can then use this log to filter out old events from the event history.
When designing any application, if you can answer the seven questions about your application to this level of detail, you probably have an initial design that's good enough to start prototyping. Obviously, the design at this point is stated only in high-level terms; it specifies almost none of the implementation details. If these are known, you could specify them in your design at this time. However, in practice, I find that it's difficult to picture all the details in advance, and even if you can, they will probably change as you implement the application. Therefore, it's best to start with a high-level design and then build a prototype to test different implementation strategies. Every real notification application I've been involved with has been built this way. |
