Architectural Overview
This architectural overview is an overview that shows the building blocks of our project. It shows how we intend to build this project, besides that it helps the development team get a shared view.
figure 1: Architectural overview
Here you can see a description of what every building block of our project means. This makes the architectural overview better understandable.
| DNS | The DNS also known as Domain Name System is Regterschot's website |
|---|
...
| . | |
| User Browser | Browser that's used by a user to access the website. |
|---|---|
| CDN | Content Delivery Network is a service that |
...
| distributes user requests to increase performance. | |
| Load Balancer | Load balancer is a REST-API |
|---|
...
| that is used to distribute incoming traffic across virtual machines. |
...
| Webapp Servers | This is the web application that we are making as the group Smalltalk. |
|---|---|
| Database | The database is |
...
| the place where we store our data. | |
| View Dashboards | To view a dashboard is an end goal so |
|---|
...
| the user can see the relevant graphs. |
Services
Services are the dependencies that our web application uses.
Google Charts
Google Charts is used so the data that we get from the database can transform to a graph thats used for the dashboard.
Data Warehouse
The data warehouse is where the data is stored of every single race.
Cloud Storage
Cloud storage is where data that is saved on the cloud is stored.
Deployment Diagram
BrokerServer
The brokerserver will run with a brokerservice on it. This brokerservice will allow us to create large data-streams. This will in turn allow us to create dynamic graphs on our webpage without having to consult a database twenty times a second. This brokerservice is connected via a broker connection to the Java application API.
DatabaseServer
The database will contain all data that is not required to be updated to show real-time data. This will thus include all sensor-data of past races, as well as all data required for logging in and creating race-views. The database system we use is MySQL, because of it's accessibility and relative ease to use. MySQL runs on a databaseServer, that is connected to the Java Application API with the use of a JDBC (Java Database Connectivity) Database Connection.
ApplicationServer
The ApplicationServer will contain the API itself. This API will use Jakarta EE and Wildfly 25.0, which allows us to run an API with ease in a web environment. Using the REST API, this Java Application will connect to a webserver and deploy its .war artifact there.
Webserver
The webserver is the link between user and API and is the part of our API that the user can interact with. This webserver could also be described as a simple website.
User PC
| Broker | The broker is used to receive live data from the sensors on the race car |
|---|---|
| Services | Services are the dependencies that our web application uses. |
table 2: glossary of architectural overviewThe user PC is the eventual device on which the API and webpage will be run. This is the user end of our application.