3. Architecture

After the first few meetings with the clients, we discussed various options and identified a temporary approach to the architecture of our system. This could be modified in the future if needed.

Since the clients would like the application to be available via the World Wide Web, we decided that using a web hosting service, such as Amazon, is the best way to ensure that. Naturally, a number of security issues arose after that decision, such as verifying that only the students and teachers of the university get access to the features of the website. After having a few meetings discussing how that could be achieved, we arrived at two options.

The first one is integrating Single-Sign-On. Since it is a University of Bristol service, we had a meeting with a representative of the IT Service of the university. We were given a list of security ensuring features that our system was required to have in order to implement this type of log in.

The second option is creating our own registration form which will verify that the user is a member of the University of Bristol by sending a confirmation link to their university email. This approach seemed to be more appropriate, so we chose to implement it over the first option and agreed with the clients on this decision. The reason for this is that since it takes less time to be integrated into the system, it will give us more opportunity to focus on other features that might be of greater importance. Single-Sign-On was therefore changed as a “nice-to-have” feature, which could be implemented in the future improvements of the application.

The basic server-client relationship is incorporated using a standard architecture of a web application. HTTP requests are collected by the server and responded to using Java. The information from the database is then sent to the client-side code and dealt with using HTML, CSS and JavaScript. These then convert it to a User Interface design which is displayed on the client’s browser.