EDUCATIONAL PORTAL ARCHITECTURE

The portal is composed of four main modules, such as server application, administration module, game module, and analytical module, which is in the draft version.

Server application

The server application is created in a Representational state transfer architecture style (RESTfull) Web API programmed in .NET CORE technology. It provides all the necessary functionalities and performs all logical operations of the portal. You need to authenticate in this module to work with the portal. The microservice architecture of this module is more detailed described in the publication (Kostolny and Bohacik, 2019). As can be seen in Figure 1, the server part consists of several libraries. Each library represents a logical entity that can ensure the modularity of the server part of the application.

The administration interface (API) is a library that contains the endpoints needed for the portal administration interface. API includes the functionality associated with authentication, user account creation, password change, logs, authority management, class management, and so on.

The game module API contains endpoints for storing information about the start of a new game, respectively, a new round in the game. It also provides storage and retrieval of game results. The shared API contains a standard functionality that needed for all other server part modules. It currently manages authentication and authorization logic, provides exception management, and includes universal models for paging lists. The security of the server part is supplied by JSON Web Token authentication, which presents as an Internet standard for creating access tokens based on JavaScript Object Technology (JSON) technology (Jones, Bradley and Sakimura, 2015).

Figure 1: Architecture model of the portal before the implementation of the test module.

A database connector is a library implemented to allow all API libraries to communicate with a database. This library provides others with a database context and the necessary objects that map to database tables.

Modul of administration

The administration interface provides the primary user-portal interaction communicates with the server part of the application. Executes requests to the server and receives responses. These answers are in JSON format. The collected data is further

displayed to the client in a mild form in the client application. The administration module using the Angular 7 framework using the Nebular UI library example of a home screen is in Figure 2. The application administration module with an analytical layer better specified in the paper. (Levashenko et al., 2016).

Figure 2: Home screen of the administration interface.

Game module

This module is the basis for interaction with pupils. The game module communicates with the server part and informs the administration module when the pupil started the game or completed some rounds of the tournament. Each game can run through the administration interface (dashboard) after successful login. The game module also communicates with the administration module through services. These two modules together form the so-called presentation layer. Closer we were dealing with the development of the game module in the article (Kostolny and Bohacik, 2017).

Requirements for the current system

The interactive educational portal is in a phase where it has prepared games for pupils and the necessary administration for user accounts of various types. For education pupils through the games, it will be required to create a mechanism whereby teachers will be able to enter questions into the system, assign these questions to the game and get results based on the pupil's answers. Therefore, one of the critical requirements for an interactive learning portal is the creation of a test module. The test module will offer teachers the opportunity to create test questions. Each question has a set of attributes that determines its classification. As it is a test module designed for pupils at primary schools, these attributes will be the year, subject, subject of the issue, respectively question category. Next, it is necessary to add functionality to share questions between teachers different schools. The module must provide basic editing questions and filtering, respectively search the list of items. The module will perform the deletion of questions based on whether or not there are answers to that question. If there are no answers, the problem can remove from the database. Otherwise, its status will be switched (moved to the "trash") and will not be available to teachers. Remove of question is not possible because the information needed in the statistical evaluation is not lost.

The test module should be independent of the other modules. If we turn off this module (e. g. for maintenance), children can continue playing, but testing will not be supported. The module will be versatile and will, therefore, apply to a system other than the interactive learning portal.

INTEGRATION OF THE MODULE TO THE PORTAL

The collection of requirements indicated the need to ensure the independence of the test module. The design of the module database is to meet these requirements. This is advantageous in terms of availability. If the primary database fails, the test module database will continue to be available. Another advantage is a more natural exchange of database types. If we need it in the future that it will be necessary to deploy a different kind of database for the test module for some reason, this exchange can be made much easier and faster than if only one central database existed. They arose during the study, two architectural designs as part of the module integration design. The first design work with the idea of clearly microservice architecture. In general, microservices (MS) is as the architectural style that divides an application into a set of services that are highly maintainable and testable (Richardson, 2019). The test module would thus become completely independent. For implementation, it would be necessary to create a so-called Gateway API (GA), which can help to aggregate queries from individual MS. GA would also communicate with the presentation layer (client application, game module).

The advantage of the first design (Figure 3) is to achieve absolute module independence. The integration of this solution is a relatively big problem, as the effort is to interfere as little as possible with the existing system. If we create a new layer of the server part, it would be necessary to reauthenticate and redefine all endpoints at the highest level and create new aggregated parameters to retrieve data from both MSs.

Figure 3: First design of architecture with Gateway API.

The second design (Figure 4) is based on the idea of creating a test module as a library.

The significant advantage is that in this case, it is possible to use services from other libraries

because the functionality from other modules are contained in their libraries and exist in one solution. There is also no need to interfere with the existing solution. The idea of its database for the test module is also easy to fulfill. It will have its database connector (library to connect) for connection.

Based on the analysis of the individual integration proposals, the second solution, which is shown in Figure 4.

Figure 4: Second design of architecture