Given that scenario, you begin to design a draft of the database schema. Of course, in the real world, you will begin by creating a list of requirements, some UML (Unified Modeling Language) schemas, and other items before designing the database, but let's compress that process for the sake of simplicity.
Most likely, the schema includes the items shown in Table 13-1. It makes sense to try to design the application to be reusable for other notification scenarios not related to birding. Therefore, you will name the common elements with generic names, allowing for their reuse without having to rewrite shared items.
It happens that the last three names coincide with Notifications Services terminology. The first item, Regions, however, contains application-specific information and has no corresponding Notifications Services term.
Bird sightings come in three categories:
Therefore, your application must fulfill the following requirements:
These two requirements lead to some changes in the application schema. We will need to keep track of:
How will you meet these new requirements?
Historical information is somewhat more complicated to manage. We need to compare the date and time the event was entered with the date and time for the last notification-sending operation. Our database schema does not include any information about when the alerts were sent. Therefore, we need to keep track of notification processing.
To keep track of notification processing, you can choose between two models:
Which one should you choose? Recording the date by type is simpler than recording it for each subscription. The former requires keeping only one record for each subscription type. The latter approach requires one record for each subscription and some logic to keep both tables (subscriptions and processes) in sync. However, in the event that a notification is not delivered, the type approach will not allow the affected subscribers to ever receive the notification. This drawback might be acceptable in some non-critical notification applications, but it is not acceptable in other kinds of applications, like those involving expected actions on the subscriber's part (a phone call to return, a contract change to act on, a customer claim, etc.). Indeed, even non-critical notification subscribers will prefer not missing any events. Therefore, for the sake of reusability and ensuring completeness, the second approach should be your choice.
Some additional requirements arise from having different devices and media to which our application must send notifications. E-mail messages should be delivered by means of an SMTP server and SMS messages by means of a text-message server. Additionally, the e-mail format, usually HTML, is not suitable for sending SMS text messages and vice versa. Therefore, the solution should be able to send different bytes to different server types. This is a configuration issue, but also something to consider in the application architecture.
Again, several options exist to implement this functionality, from hardcoding the message-building process in the application to using third-party software that handles the conversion process. Notification Services solves this issue with openness in mind: you must supply an XSLT (eXtensible Stylesheet Language Transformation) file for each device type (to be comprehensive, you will need an XSLT file for each device and locale combination). An XSLT engine can use an XSLT template to transform an XML input to some other type of output (HTML, XML, or text). Therefore, this is a very suitable way for meeting most requirements.
The application's internal processes will manage information in a format that is not user friendly. For instance, the application refers to every item by ID number instead of by Name. However, when preparing the data for actual end-user delivery, translating IDs into textual information is mandatory.
In order to accelerate the final notification generation and its delivery, you should prepare the information that this process needs. For instance, instead of storing the Region ID, you would store the Region Name. You would also store the Event Description instead of the Event ID. Thus, when the engine decides to send the notification, it will not need to look in several tables and perform joins to get the information it needs. It will simply read a record from a table where all data is prepared according to its needs, ready to be sent out.