EAs.LiT is an e-assessment management and analysis software for which contextual requirements and usage scenarios changed over time. Based on these factors and further development activities, the decision was made to adopt a microservice architecture for EAs.LiT version 2 in order to increase its flexibility to adapt to new and changed circumstances. This architectural style and a few adopted technologies, like RDF as a data format, enabled an eased implementation of various use cases. Thus we consider the microservice architecture productive and recommend it for usage in other educational projects. The specific architecture of EAs.LiT version 2 is presented within this article, targeting to enable other educational projects to adopt it by using our work as a foundation or template.
EAs.LiT is a web application handling e-assessment item and learning outcome lifecycle, - management, - annotation, as well as automated exam creation and exam analysis, as introduced by Thor et al. in [9]. In 2018 the German Federal Ministry of Education and Research granted further development of the software EAs.LiT as part of the tech4comp project. With respect to the demands of this research project, but also as time passed by, new and adapted requirements and usage scenarios arose for EAs.LiT. The original software was built using a monolithic system architecture and imposed several challenges regarding maintenance, expandability, reusability, and repurposibility as of the evolved context, like argued by Newman in [7] for monolithic software systems in general. Thus we decided to develop EAs.LiT version 2 with a different and more suitable software architecture, namely the microservice architecture, which tackles the named topics. It offers even more advantages in comparison to a monolithic architecture, like argued in detail by Newman in [7]. ? This work was supported by the German Federal Ministry of Education and Research for the tech4comp project under grant No 16DHB2102.
We consider the microservice architecture productive and recommend it for usage in other educational projects. Thus the focus of this paper is to present the architecture of EAs.LiT version 2 in section 3, as well as its accompanying technologies RDF and JSON-LD. Furthermore we showcase in section 4 the implementation of specific use cases, which were eased by the architecture and used technologies. Our main goal is to enable educational projects to adopt the architectural style, using our work as a template. To achieve this goal, we additionally present in section 2 related work that focuses on software projects which also use a microservice architecture. We end by summarizing our approach and emphasizing unique features, as well as presenting future development topics. 2
SlideWiki, which may be considered a Github for slides in the educational context, uses a microservice architecture, which was presented by Khalili et al. in [5]. They mainly focus on distributed development and collaboration of teams. In contrast to their work and software we do not focus much the social aspects of the architecture, but on technological aspects, like the use of semantic technologies in all architectural layers. Furthermore we showcase novel integration scenarios, like the use of spreadsheets as a batch processing frontend.
Kumar et al. propose in [6] to utilise a microservice architecture for e-learning systems. They unveil that it is a solution to several downsides of current monolithic e-learning systems and constructed a simple, but theoretical example. Similar to our own work, they propose to use several web technologies, but are not providing an implemented proof of concept and only scratch the topics surface.
Fazakas et al. present in [4] a novel virtual classware technology which uses a microservices architecture. They mainly focus on their use case and developed software and only lightly touch the software architecture topic. Microservices are named an enabling technology for their solution and they used similar web technologies to the ones we used. In contrast we focus less on the built software, but much more on the architecture itself and why using it enlarges the flexibility of the software system.
Rad et al. propose in [8] an "innovative technology that implements problembased learning and projects-based learning concepts". They utilise a cloud infrastructure for their solution and run several microservices as part of it. No exploration of the decision was presented and they seem to use it as it fits their needs and is supported by the utilised cloud stack.
There are much more software architecture publications available, focusing on microservices. In contrast to the presented literature these publications focus on different aspects of the architecture, like scalability and incremental updates, target different use cases, like delivering large amounts of data to end users, and are not positioned in the educational software context. Thus we do not present these here, but wanted to mention their existence.
EAs.LiT version 2 implements a microservice architecture, as introduced and argued in detail by Newman and Wolff in [7,10]. This means that the software system is not executed as a monolithic system, like EAs.LiT version 1, but is composed of several independent and fine grained services. These services are built using a domain-driven design approach, described by Evans in [3]. Each service implements a distinct and enclosed domain of the whole system. As of the current project progress there are services for the domains: 1) item management, 2) data format conversion and data import/export, 3) media management, 4) the end user frontend, 5) data management (database), 6) item annotation, 7) traffic management (a reverse proxy), and 8) item batch editing. Within the following paragraphs we present and discuss all parts of the new EAs.LiTs’ architecture, using a birds’-eye view depicted with figure 1.
Web App (
Spreadsheet (
Annotation
Service (
Mediator (
Media Service (
Others
e.g.
Mentoring
Workbench
Data format
Service (
Figure 1 shows in the upper left corner two end user applications: the main
frontend of EAs.LiT (
Service 7 (traffic management) is a reverse-proxy server and used to route incoming and outgoing traffic correctly and to handle traffic encryption, rate limiting, authentication and other related topics. It is a mediator (like named in figure 1) or gatekeeper between software running on our infrastructure and software executed elsewhere. Its purpose is to free service developers from implementing the just named topics to each service and allowing them to focus on their specific domain only. Currently we use a NGINX based reverse-proxy server3.
Microservices 1,2,3 and 6 focus on different distinct domains, like item
management and item annotation. All of these services implement a representational
state transfer (REST) interface, utilizing OpenAPI (formerly known as
swagger) for standardized interface descriptions. A REST interface allows to easily
incorporate services from each other, from the official fronted (
Lastly we depicted various data storage services (
As of noticeable technologies, RDF 4, serialized to JSON-LD5, is used as the central data format through all of the above described services. These technologies impose extra effort for data management and processing, but ease a lot of use-cases on different levels, like presented in section 4.3. RDF is a open
world data format and thus easily extended with new data, without running into
structural limits like introduced by entity relationship models. JSON-LD, which
is one possible serialization of RDF data, adds a context to traditional JSON
documents. This additional context may be utilised by software like the
frontend (
Within the following subsections we present special use cases and implementations of these, which the described architecture from section 3 enabled and eased to implement. We treat these use cases as proof of concepts, research prototypes and examples on how the named technologies may be efficiently applied. 4.1
The Mentoring Workbench (MW) is the main software product of the tech4comp project (to be described in future work) and provides several web-components, that are activatable in different places of a Learning Management System (LMS). Some components are usable by students, others are usable by educators and supervisors. One component the MW provides is a personal exam analysis tool for students. It links available e-assessment items to exam results from the LMS and pulls additional data from EAs.LiT to create a detailed analysis of the individual exam results. The component relies on item annotations, such as levels of Blooms taxonomy about the cognitive learning domain [2], manually added by educators. The annotated items are pulled and processed by the MW and merged with the LMS data in order to e.g. inform students about reached performance levels.
The architecture presented in section 3 eased this process as the MW pulls in
items via the already existing item management API (
As broached in section 3 we implemented an item batch processing interface as a
plugin for Microsoft Excel, depicted in figure 2. This plugin is written in Visual
Basic for Applications and automatically included as item sets are exported from
EAs.LiT via the import/export service or via the frontend. Nevertheless the
plugin is also usable on its own when provided with an EAs.LiT instance reference
(URLs for the item management and import/export services). The plugin allows
to fetch item sets from EAs.LiT, to use the capabilities of spreadsheets for batch
editing and processing and to upload the updated items back to their origin.
Spreadsheets efficiently allow various batch editing capabilities for items, like to
increment the number of given points, to compare and exchange answer texts,
to revise item annotations, like presented in section 4.1, and to create a lot of
similar items by copy and paste operations. In comparison to EAs.LiT version
1, several manual steps for data export and import via the browser interface
would have been needed. Even more importantly the already existing services
supported this use case without the need to apply any changes to their API.
One goal of the tech4comp project is to create preferably complete knowledge
graphs for specific domains, like the educational discipline. For various use cases
it is desirable to link learning outcomes and items to this graph, e.g. to provide
the ability to analyse the item/domain distribution. As broached in section 3
items and learning outcomes managed by EAs.LiT are stored as RDF data, as is
the knowledge graph. We hinted in section 3 that RDF allows to link data sets,
but does not require to merge these in order to do so. So for example a specific
item is annotated with a specific domain from the knowledge graph by adding
the URI of this domain to the item. Thus the used data format allows a fast and
straight forward implementation of this use case. Because RDF is an open-world
data format, adding new data (even on a structural level) will not break any
existing services, like the item management service (
Based on these facts we realised a frontend component which allows to visually analyse the item/domain distribution, depicted in figure 3. This component merges the received item and learning outcome data, as well as a reduced view of a knowledge graph, received directly from the knowledge graph store. The result is presented as an explorable canvas to end users. Because of the RDF technology, various RDF data serializations and the microservice architecture, we were able to skip implementing complex merge strategies or rule sets as the different data sets just need to be appended into a single data record prior to being displayed. 5
A particular adoption of the microservice architecture for an educational software project has been presented and explained at the example of EAs.LiT version 2. We focused on the concrete software architecture in order to enable third party projects to learn about the architectural advantages and to adapt it for their own software projects. Furthermore novel use-cases have been discussed, which were either enabled or at least eased to realise because of the used architecture. Several technologies are accompanying the various use cases of EAs.LiT and thus we presented RDF and JSON-LD as key data formats, used through all the architectural layers. Characteristics of these two technologies complement benefits of the microservice architecture and also enable and ease some of the presented real-world use-cases and prototypes.
As mentioned in section 3 we are using different data stores for different usecases. Our current data store lacks the native ability for version management (of items). Thus we plan to incorporate the quit-store, a graph store which is based on the distributed version management software Git, presented by Arndt et al. in [1]. This new store fits natively into the microservice architecture and may be used whenever end users need access to former data versions. Furthermore it allows efficient exchange of data via the git distributed repository strategy, usable for data sharing between different EAs.LiT instances, e.g. hosted by different universities. 6
The application EAs.LiT consists of several services, licensed under Mozilla Public License Version 2. The source code of these services is available as different Gitlab repositories, listed as of this filtered project overview of the tech4comp Gitlab group at https://gitlab.com/Tech4Comp?filter=eas.