|Novel Approaches to the Monitoring of Computer Networks|
|Prev||Appendix A. SMS-based Reporting System||Next|
The most obvious extension to the simple service described in Section A.4 was to integrate it with a database. This database keeps track of which clients send what messages, and can later be used to handle incoming SMS messages as well. The connection labelled (2) in Figure A-1 above shows how this database links into the web service.
When a client sends an SMS message, a corresponding entry is created in the database. This entry contains the client's username, the date and time the message was sent, the hostname the client connected from, the status of the message, and optionally the message itself. A unique identifier represents each entry, and this identifier is returned to the client in the SOAP response.
The date and time, and the client's hostname effectively form a log of the activity, and are useful for tracing faulty connections or abuse of the service.
The status field is an indication of the status of the message. At present, this field simply confirms whether or not the message was sent out by the service. In future, however, it may serve to hold information on the delivery status of the SMS message.
Storing the message itself may be a contentious issue. The main advantage of this is that it allows a client to request messages that they have previously sent. This is done using the unique identifier that was returned to the client, and may be useful for providing context information. The disadvantage, obviously, is the possibility for invasion of privacy. The web-service's access control rules prevent users from retrieving messages sent by other users. The safe storing of messages, however, depends on the service administrator being both trustworthy, and sufficiently securing the server from unauthorised attacks.
Having a database backend allows other applications to interface with the service. For example, an accounting application can use the database backend to work out SMS charges.