Microservice architecture provides on a set of modular, independent and fault-tolerant services. In recent years, new architectures have evolved with an emergence of recurrent, and e ective architectural patterns essential in maintaining and scaling microservice-based systems. However, in the domain of education there is a lack of open-source, microservice-based systems that are easily con gurable for various teaching, research, and commercial purposes. Preferably, these services should be orchestratable as part of other education-related service compositions as well. In this paper, a study of microservice-based learning management systems is conducted by focusing on two systems that the authors are involved in: WETO and Plussa. We report the current status of these systems through the lens of microservice architecture and draft a proposal for the synthesis of an ideal, decoupled learning management system.
Learning environments and Learning Management Systems (LMSs) have been
in focus of active development and research. However, the development is led by
multinational companies whose topmost interest is commercial. The cross bet
between non-pro t organizations and commercial actors is far from unseen. In
the domain of scienti c publishing, it has led to the situation where some data
is freely available, and some are behind the paywall of commercial journals. This
is an obstacle from the viewpoint of open data: publications on the other side of
the wall will get less reads and references. Research Data Alliance (RDA) works
against these obstacles and promotes openness and reuse of data [
In Finland, opening public data sources started approximately in the
beginning of the 2010s, which triggered such initiatives as Open Data [
Land Survey of Finland [
In Finland, education is a public service sustained with tax money, where
the 2019 government programme states: An equal society seeks to provide
opportunities for every citizen to study to their full potential [
DEFA provides a shortcut to university studies: participants can just take individual courses, or compile courses as bigger and meaningful entities, with a bonus of being accepted as a student, dependent on one's success. All the studies are available as MOOCS, enrolling several thousand participants simultaneously. An example of this is *Elements of AI, a prize-winner MOOC implemented by University of Helsinki that introduces arti cial intelligence theory with practical exercises. FITech network lls the digital skills gap and prepares ICT professionals for the industry, the initiative is called FITech ICT. It runs for three years and the target output is 4000{5000 ICT-savvy individuals. Smart Learning Environments project develops and expands university-speci c e-learning environments (including automatic validation, visualizations and simulations) for national inter-university use. As its sub-project, the material converter from LaTeX to RST, or shortly *LaRST, seeks to nd underlying ultimate data format, where Latex is upvoted by mathematicians, in particular. The original Latex content can then be printed as a book or converted to on-line course area with auto-assessed exercises.
In the development of reusable learning materials and exible infrastructure,
the key to success from the technical point of view are such architectural choices
that maximize exibility and the independence of services. By the same token,
microservices have trended since 2014 [
Next, we introduce our research context, the LMSs used more in detail, followed by a short explanation of the method used. Next chapter summarizes
the currently identi ed state-of-art solution, as the target state of our LMS development. In the Discussions and Conclusions section, we validate our results and ponder critically di erent architectural choices made and (false or overemphasized) promises attached to them. 2 2.1
This study follows loosely the method of feasibility study [
In the evolution from monolithic to microservice architecture, WETO resides in a more monolithic position than Plussa that can be described largely serviceoriented. In comparison with more traditional service-oriented architecture, microservice architecture stands out as being more decoupled, its services can be deployed independently and scaled horizontally with proper load-balancing mechanisms.
Using microservices each learning service can be developed and deployed independently, which makes the exploitation of common resources easier. Developed learning materials exemplify such resources, and they should be as exploitable and open as possible keeping in mind that the funding comes from the Ministry of Education. The target is that reusable parts of learning materials and gathered data will be publicly available for all national actors and service providers mainly in the domain of education and employment services. 2.3
WETO2 is an LMS developed and used at Tampere University since early 2000's. Its core features are: { Basic content management: course pages may be created/edited using a browser, e.g., images and les may be uploaded and linked to the pages. { Submission management: pages may upload student submissions (e.g. homework or exam answers). { Grade management: pages may comprise student grades, and grading rules may be de ned hierarchically:
E.g., the top-level page could show overall course grades, its \Exercise"and \Exam"-sub-pages exercise and exam grades, respectively. { Automated grading: submissions may be graded automatically. WETO has a built-in support for multi-choice questions; programming tasks can be graded by an external grader. { Rights management: pages may de ne permissions for viewing and uploading submissions, these permissions may be time- and student-speci c. { Peer-reviewing: submissions may be peer-reviewed anonymously. { Basic discussion forum: pages may have a forum where teachers and students can discuss learning-related issues. Students remain anonymous.
WETO is a fairly traditional Java EE 6 Servlet application. A WETO instance needs WETO Java EE application adatsaibnagslee anPdosotngereoSrQmLoremPasotsetr- Authentication CouUrsseerenrirgohlltms ent Grader 1 icgmnorfaeuosSrrtsQmeerLsa.dtiacCootnoauubrrsaasesbeeoddcuaoattntaatbaubaisansesesresssg.locTaobnhnade-l dMataasbtaesre MaAteUnrBoisSaenalurysb(imacHmeciTttgziciservM.sadiitdoLyfinon+slrgougmles) GGraraddeerrms tain course-speci c information sduecnhts,asgrtaedaecshearnsd, esnurbomlleisdsiostnus-. daCtaobuarssee 1 Course databases daCtaobuarssee n Each course database may host several courses. In principle, the WETO instance may be con- Fig. 1. WETO architecture. nected with one or more heterogeneous external automated graders. A restriction is that each external grader needs to directly manipulate WETO's course databases, which implies the need to implement WETO-speci c middleware for any non-WETO-speci c grader. The architecture is illustrated in Fig. 1. Evidently, WETO itself is a monolithic application even though the mechanism of exploiting external graders might resemble microservices. 2.4
Plussa is Tampere University's application of A+ of Aalto. Plussa divides into
two parts: a front that takes care of role-based authentication (students, teachers,
admins), and stores grades, the other part is MOOC grader that runs in the
background invisible to the user and manages courses and provides such built-in
exercise types as multi-choice questions [
The A+ platform manages user authentication and authorization, stores
submissions and grading results (feedback and points), manages course con guration
and setup, provides course monitoring (student progress and statistics) and web
user interfaces for students and teachers. [
One major design principle
of Aalto A+ was to provide an
easily extendable, service-oriented
architecture that could be
enhanced with di erent services, for
example, with new graders for
automated assessment [
In addition to LTI services, A+ LMS can be extended with graders. The graders do not require separate authentication, since a student has already been authenticated by A+ frontend. If the grader runs in a separate server, such as in Fig. 3, this is signi ed in the exercise con guration with the *submit RST directive and by giving the URL to the exercise. The exercise itself is represented inside an iframe element (1), and after completion when the student presses Grade button (2), grading is done and points are returned to A+, which stores the results (both feedback and points) in its database. In Fig. 3, grading is done by an external grader. Other options exist, e.g., grading within temporary docker containers, or submitting exercises to a separate Kubernetes cluster for grading.
Automatic assessment with
graders has been one of the
principal goals when construct- Front: user
authening A+. The work began with tication/grades, exercise and its
a literature review of di erent cMoOurOseCregpraodsietro:ry grading
auto-assessment systems. In the
rseiovnie/wre,ssuubcmh ifsesaiotunr,esmaasnsuuablmaiss-- student:(1) opens an exercisePlussa: Grader:
sessment options, sandboxing, exercise put in iframe foGrmETmseetrhvoicdePUORSLT
distribution and availability of (2) POST form
dwiithertehnet mLiMndSssetwoefrdeeseixganminigneads gets graded points
decoupled assessment system as
possible [
Git and SonarQube In their A+ study, Karavirta et al. divide the
assessment systems in three categories: synchronous, asynchronous, and static [
The industry partners of Tampere University have listed Git skills to be
an important asset, which is con rmed by Haaranen's study, which corroborates
their high demand in the software industry, and the emphasis on their importance
in the literature as well [
In the strategy of Tampere University, Git system will be exploited even
further: continuous integration pipeline is set on, unit tests are automatically
run when a submission is pushed to the Gitlab repository and SonarQube static
code analysis is available for a course personnel as well as students for
selfre ection of the quality of their code. Besides auto-testing, the bene t of the
pipeline for continuous integration is that students familiarize themselves with
the DevOps development that is another skill appreciated by employers.
Learning analytics and gami cation More recent studies in Aalto has
concentrated on adding gami ed features and learning analytics to the LMS. Gami
cation includes such new features as earning badges [
In addition to engaging students with gami ed user experience, A+ improves
teachers' view of the learning process as a whole. Lehtinen et al. note that
teachers' want to monitor the expected progress of their students, improve allocation
of learning material, identify problematic areas in learning material, and improve
interaction with learners [
In LukioPlussa, new graders for math exercises were added as internal graders
such as MathCheck, Geogebra, and Abitti. The ease of adding new graders
demonstrates that the plug-in architecture of A+ provides e ortless extensibility.
In addition, interoperability is ensured by using consistently agreed protocols,
such as proprietary A+ protocol, and widely adopted LTI standard.
A+ protocol The A+ grader service protocol is de ned in the GitHub in
Grader's README [
LTI protocol LTI is a speci cation developed by the IMS Global Learning
Consortium whose main purpose is to provide a standard way of integrating
learning tools [
The LTI de nes a standard way in which LMS can communicate with an
o -platform learning service provider. When the LMS aims at using the service,
it sends a signed POST message with a browser. In signing the request, OAuth
protocol is used, which e.g. enables an application to use e.g. Twitter or Google
for authentication. LTI allows single-sign-on, a student needs to authenticate to
the LMS only { not individually to each service used in a course. Once student
is logged in LMS, external services linked to the platform via LTI will be
informed by the platform that the user has already been authenticated. Thus, a
student does not need to register to yet another service. For example, MATLAB
supports LTI, therefore being integrable to Plussa [
LMS with a decoupled microservice architecture As discussed in Section 1, one of the main goals of the Smart Learning Environments project is to nd ways to share university-speci c LMS resources across di erent universities. Due to the heterogeneity of the systems, and lack of consensus, convergence towards a single common LMS is unlikely, but with the setting of a more modest target, the way to advance this objective would be via migration towards microservice architecture. Highly decoupled and independent microservices would lower the threshold of sharing them among universities, although di erent universities would still use their own LMSs. Hence, this section sketches out a microservice-based LMS oriented towards exible reuse of its components. 3.1
{ Page hosting should be minimally restricted. The LMS will be used via a web browser, hence the requirement is that the course pages can be hosted by any type of web server/service, for example, a generic web-content management system, such as WordPress. { For the sake of simplicity, the authentication method should be common for all services, preferably with a wide, existing support, e.g.: a token-based method: an authentication server provides the LMS frontend with a token (e.g. JWT) to be included in each request, the widely used LTI protocol (see Section 2.4) quali es as well. { LMS features should be split into independent (micro)services that assume minimal mutual knowledge and dependence. { Each service should provide both a web API and a reference implementation of a frontend component (HTML, JavaScript etc.) for accessing the service. The API should provide facilities to get a response from the service as plain data (preferably in JSON).
Many existing LTI-based services send pre-rendered HTML content to the service consumer. Our proposal is more stringent, as we strongly suggest that each service provides also a data-only type API to enable the migration towards microservice architecture.
A reference frontend component could lower the threshold for incorporating new services. Preferably, the reference implementation only needs tweaking its context-speci c con guration parameters, e.g., application ids and service URLs, to be embeddable as a new service to an HTML page 3.
Fig. 4 sketches our proposal for a microservice-oriented LMS architecture and
answers to rst research question: The main component is the user/rights
manager with a centralized responsibility for maintaining information about course
membership roles and more speci c user rights. When a user accesses the LMS
through a view provided by the host, the system authenticates the user, if
necessary. The authenticated user receives an authorization token that will then
be attached to all LMS service requests. Each service uses the token to verify
the identity of the user and to consult the user/rights manager about the user's
roles/rights. This solution is similar to the one proposed by Baier and Allen [
Furthermore, the sketch suggests grade management, discussion forums, user activity logs/analytics, and automatically graded exercises as the core functionalities of the LMS. For decoupling, each service should maintain its own database. In service access, a request typically entails course and user ids that are unique, which is enforced by the authentication and user/rights managers. The sketch also depicts nested services: a service itself might employ sub-services; e.g., automated grading may use separate grader services.
Optimistically, this sketch implies independent services that are capable of
performing their tasks without employing any other services. Inter-service
communication would mandate the implementation of e.g. an asynchronous message
queue: a typical solution for service interoperability via HTTP with an inherent
decoupling [
to allow AJAX calls to the services.
This paper reviews the migration of LMSs from monolithic taorwchairtdecstmuroer.e mTaicmropseerrevicUen-bivaesre-d Generic HTML host Gra1der sairtey LtaMkeSns, Was EsTtaOrtainngd Pplouinsstas,, Authentication Rteockeeinve (H[ATcMceMLss/aetselersisea/rlevticce.?s) GGrramaddeerrs and are then analyzed and using AJAX] synthesized into one modern Token Token Automated tmhiecrroesseurvltiscea-breasseudmLmMaSri.zeNdexats, mGarnaadgeer Token Token Token grading trieosnpso.nsResQt1o: thTe hreesecaorcrhe qumesi-- Database Rights? Umsearn/raiggehrts Rights? Database croservices of an LMS Autuhseenrtiacantdionc,ourmseanaingfeomrmenattionof, sFeorrvuicme Rights? Database Rights? Asnearlvyitciecs grading, and providing reports Database and analysis. Database
vice provision of Tampere Fig. 4. A decoupled microservice architecture.
tinuum from monolith to microservice architecture, WETO is more to the left, but taking steps to serviceoriented direction. Plussa mainly waits for an agreed common exercise format and the anticipated outcome of LARS project, i.e., the Latex to RST converter. In addition, teachers' user experience is defective in many respects, leaving a lot of space for improvement.
authentication services are of paramount importance. In general, LMS should
provide open, reusable and standard services that can function independently.
Standard solutions are promoted, such as LTI for authentication and grading.
Other standard solutions include: Sharable Content Object Reference Model
(SCORM), a set of speci cations for creating and sharing e-learning [
The bene ts of microservice architecture become more apparent when the target is to co-operate between multiple universities, such as in Smart Learning Environments project, i.e., when the complexity of a system increases. Then, micro-architecture may facilitate better coordination, re-usability of resources, such as learning material, and orchestration of di erent services represented in Fig. 4. However, we want to highlight that there are problems ahead and too much unfounded hype: microservice architecture will provide neither a single point of failure nor easy logging, and service orchestration is, in fact, quite complex. Cooperation with many players is not supposed to be smooth, e.g., sudden and poorly informed changes may cause discontinuities in service provision. Thus, realization of this vision requires a lot of work, good will, and co-operation.
P.Niemela et al.