CLM research and development projects
The Fraunhofer-Gesellschaft, particularly its institute Fraunhofer FOKUS, has been involved in a series of research and development projects related to educational technologies. The most significant groundwork in this context is the Common Learning Middleware (CLM) development project, which was implemented in two phases from October 2018 to August 2021. In the past, approximately 50 teaching and learning technologies were implemented as isolated solutions by individual Fraunhofer institutes, which were not interoperable with each other. In order to unify these in a common infrastructure and later address similar needs from the industry, the development of the middleware was initiated by the Fraunhofer Academy, as the central demand holder of the Fraunhofer-Gesellschaft, and Fraunhofer FOKUS, as the leading institute for implementation. In CLM Phase 1, a feasibility study, breakthrough, and initial technical prototype were implemented as an interoperable service mediator until December 2019. In CLM Phase 2, from September 2020 to August 2021, the CLM was expanded for productive use in organizations and enhanced with translation functions between standards, specifications, and data formats.
The CLM is based on open standards and specifications for educational technologies, including standardized interface definitions and persistent activity data, metadata specifications for content structures, as well as learning objects for knowledge dissemination and assessment. It has been developed as a multi-tenant component for various educational actors and institutions. Through the CLM Management Service, the Common Learning Middleware enables the management of user roles and enrollments in learning objects or entire courses and handles access control for learning content and services. The CLM consistently relies on interoperable standards. Accordingly, services that adhere to the same standards can be directly integrated. These include the following in particular:
- User interfaces (applications, LMSs, portals, apps) presenting the content and offerings orchestrated by the CLM for end users such as learners, educators, as well as organizational and administrative personnel
- Existing user directories and Single Sign-On solutions
- Databases for storing profile, enrollment, or activity data (especially Learning Record Stores)
- Repositories/databases for learning materials providing media and metadata
- Additional services (Service Providers) providing interactive or adaptive learning content, such as VR/AR services, Learning Analytics components, AI systems, competency management, personal certificates/credentials, portfolio management, HR tools, etc.
In the underlying concept, elements intended to be offered in applications for users, whether it’s text, an image, a video, a dashboard, or virtual reality, are abstracted as learning objects (also known as Launchable Objects or Tools). The offering servers, which provide media and services for the infrastructure, act as Service Providers and can register their offerings in the middleware (publish/subscribe). A Launchable Object can be connected via the middleware’s interfaces in a standard-compliant manner and made known to the application. Accordingly, the object is not copied to another server system but directly accessed from the original service provider.
Supported Standards and offered interfaces
The Common Learning Middleware promotes data standardization and the use of unified datasets and interfaces, which serve secure yet interoperable data exchange. This approach prioritizes users, especially learners, who can seamlessly access content and services from different providers and share their data across them. As a service, the CLM provides interfaces for decentralized integration of various stakeholders. Providers of learning content can register their offerings as tools or service providers with the Common Learning Middleware.
Basic functionality of the Common Learning Middleware | © Fraunhofer FOKUS
The CLM Management Service enables institutions to manage offerings and end users. For the latter, no new usage account needs to be created within the service; instead, it leverages one of the stored Single Sign-On Providers (e.g., Open ID Connect) or directory services (e.g., LDAP) to reuse access securely. However, it is also possible to register a new usage account in the Management Service if no existing identity can or should be used. Usage accounts can be manually or automatically assigned (“enrolled”) to courses and Launchable Objects by educational authorities. Regarding learning content, different roles and permissions exist per usage account. For instance, an instructor, if permitted by the learning object, can make adjustments to the learning content, while a learner can only access the finished content.
Learning content, media, and services can then be integrated into applications for end users as Launchable Objects. The Common Cartridge data exchange format allows the exchange of the didactic structure of all learning objects in which users are enrolled. Besides cmi5, the CLM supports the Learning Tools Interoperability (LTI) specification (in versions 1.1, 1.3, and Advantage) for integrating linked learning objects. This involves a secure call (LTI Launch Request) of learning objects, reflecting the trust relationship between a Tool Consumer or platform (the application for end users) and a Tool or Service Provider (the provider of learning content) based on established web standards. A Launchable Object contains either pre-rendered HTML elements or content metadata, which must then be suitably presented by the platform. During a launch, the required data is signed by the platform – the CLM handles the signing, minimizing the platform’s administrative effort for LTI configurations. Additionally, another “Launch” mechanism supported is ADL cmi5 (a part specification of xAPI), which also relies on established web standards. However, cmi5 follows an alternative approach where request data is not signed but instead, a token is exchanged, provided by the CLM.
The CLM verifies user data and associated roles and access rights with each interface request. During a “Launch” request (i.e., the application’s request to present a Launchable Object to the user), the request data is signed with the user information (LTI) or based on its token (cmi5) and transmitted to the Launchable Object via the Service Provider. The CLM also facilitates translation between different launch mechanisms, such as LTI 1.1, LTI 1.3, LTI Advantage, and cmi5. This enables providers to offer cmi5 objects, for example, which can be loaded into applications as LTI Tools in a specific version (and vice versa).
User interaction data (Learning Records) can be captured in the application or in the respective learning objects. For this, the Launchable Object requires user information, which is transmitted during both “Launch” mechanisms. The Experience API (xAPI) specification from ADL and CALIPER are supported for capturing Learning Records. These Learning Records can be persisted in Learning Record Stores (LRS). Educational institutions can register and configure their own LRS with the CLM, specifying which types of Learning Records from which tools users should send to which LRS during interaction. The CLM orchestrates and secures the trustworthy interaction between Learning Record Providers (which produce new Learning Records from interaction), Learning Records Stores (as databases for managing pseudonymized interaction data), and Learning Record Consumers (which process stored Learning Records, e.g., AI services). The CLM manages service permissions and their access to Learning Record Stores.
All CLM interfaces are RESTful APIs (Representational State Transfer Application Programming Interface) – interfaces according to the paradigm for software architectures of distributed systems. The interfaces have been specified and documented according to the OpenAPI specification and can be tested by developers via an OpenAPI compliant interface such as Swagger UI. For relevant interfaces, such as providing LTI-based tools as Tool Providers, validators have been implemented, which validate new learning objects against their specification when integrating with the CLM and potentially highlight misconfigurations.
CLM Management Service
Although the Common Learning Middleware primarily functions as a mediator service, responsible for linking institutions, learning platforms, content, and services, it also includes its own Management Service as a modular sub-service for participant management. The Management Service enables the utilization of a role and rights concept for managing various participating institutions (referred to as tenants here), users, services, contents, and allows the administration of user roles and their access rights. The CLM Management Service distinguishes between different levels:
- Global administration level: At this level, platform operators can configure global settings and manage educational institutions and development accesses.
- Institutional administration level: Each institution can register and manage its own content and services, assign user roles to these services, and enroll users in individual content or entire courses.
- Institutional developer level: Each institution can utilize a range of technical interfaces (APIs) provided by the CLM. For instance, to register their own content or services with the CLM (publish/subscribe), authenticate end-users to their applications via the CLM using single sign-on, integrate content and services into their own applications, or store learning activity data (Learning Records) in separate Learning Record Stores. Passwords for using these interfaces (Development Keys) are assigned by global administrators to the institution’s developers. These keys ensure that only authorized developers can access the CLM and its offerings and that authorization for interface usage can be revoked in case of misuse (e.g., certain cyber-attacks).
- End-user level: End-users do not directly interact with the Common Learning Middleware and are usually unaware of its existence. Instead, they use an app, learning platform/learning management system, or other user interfaces provided by the institutions and connected to the CLM (referred to here as learning applications for simplicity). In this application, users can either use one of the stored single sign-on solutions (e.g., OpenID Connect, LDAP) to log in with their existing credentials or register a new user account with the CLM’s own management service. After authentication, users can then access content and services according to the enrollments and roles stored by the institutions.
Graphical interface of the CLM Management service | © Fraunhofer FOKUS
In addition to the graphical management of users, learning objects, and activity data, the CLM also offers important functions for data protection. For example, user IDs are pseudonymized (using a hashing algorithm like SHA-256 and a salt) for any communication with external services. The assignment of a pseudonym works only in one direction and there is no assignment table: With knowledge of the user ID (e.g., in the application), the CLM can create the pseudonym and pass it on to other services for further processing. However, the pseudonym itself cannot be used to infer the ID or other personal data.
The management dashboard is used to visualize anonymized aggregate numbers of currently connected educational institutions, users and their roles, tool providers and tools, as well as daily anonymized statistics on accessed tools and generated learning records.