Common Learning Middleware: Details

Forschungs- und Entwicklungsprojekte zur CLM

Die Fraunhofer Gesellschaft, allen voran ihr Institut Fraunhofer FOKUS, hat an einer Reihe von Forschungs- und Entwicklungsprojekten mit Bezug zu Bildungstechnologien gearbeitet. Die wichtigste Vorarbeit in diesem Zusammenhang ist das Common Learning Middleware (CLM) Entwicklungsprojekt, welches von Oktober 2018 bis August 2021 in zwei Phasen umgesetzt wurde. In der Vergangenheit wurden ca. 50 Lehr-/Lerntechnologien als Insellösungen durch die einzelnen Fraunhofer Institute umgesetzt, die bislang nicht untereinander kompatibel waren. Um diese in einer gemeinsamen Infrastruktur zu vereinen und später ähnliche Bedarfe aus der Wirtschaft zu adressieren, wurde die Entwicklung der Middleware durch die Fraunhofer Academy, als zentraler Bedarfsträger der Fraunhofer Gesellschaft, und dem Fraunhofer FOKUS, als federführendes Institut für die Umsetzung initiiert. In CLM Phase 1 wurde bis Dezember 2019 ein Machbarkeitsnachweis, Durchstich und erster technischer Prototyp als interoperabler Dienste-Mediator umgesetzt. In CLM Phase 2 wurde im Zeitraum von September 2020 bis August 2021 die CLM für den Produktiveinsatz in Organisationen ausgebaut und um Übersetzungsfunktionen zwischen Standards, Spezifikationen und Datenformaten erweitert.

Die CLM basiert auf offenen Standards und Spezifikationen für Bildungstechnologien, darunter standardisierte Schnittstellendefinitionen und persistente Aktivitätsdaten, Metadatenspezifikationen für Inhaltsstrukturen, sowie Lernobjekte zur Wissensvermittlung und -überprüfung. Sie ist als mandantenfähige Komponente für verschiedene Bildungsakteure und Institutionen entwickelt worden. Über den CLM Management Dienst ermöglicht die Common Learning Middleware die Verwaltung von Benutzerrollen und Einschreibungen in Lernobjekte oder ganze Kurse und übernimmt die Zugriffskontrolle für Lerninhalte und -dienste. Die CLM setzt durchweg auf interoperable Standards. Dementsprechend können Dienste, die den gleichen Standards folgen, direkt angebunden werden. Dazu gehörten bislang insbesondere:

• Benutzerschnittstellen (Applikationen, LMSe, Portale, Apps), welche die von der CLM orchestrierten Inhalte und Angebote präsentieren, für Endnutzende, wie Lernende, Lehrende sowie organisatorische und administrative Verantwortliche
• Vorhandene Benutzerverzeichnisse und Single Sign-On Lösungen
• Datenbanken zur Speicherung von bspw. Profil-, Einschreibungs- oder Aktivitätsdaten (insbesondere Learning Record Stores)
• Repositories/ Datenbanken für Lernmaterialien, welche Medien und Meta-Daten bereitstellen
• Weitere Dienste (Service Provider), welche interaktive oder adaptive Lerninhalte bereitstellen: z.B. VR/AR Dienste, Learning Analytics Komponenten, KI-Systeme, Kompetenzverwaltung, Personenzertifikate/ Zeugnisse, Portfoliomanagement, HR-Tools, etc.

Im zugrunde liegenden Konzept werden Elemente, die in den Applikationen für die Nutzenden angeboten werden sollen, sei es ein Text, ein Bild, ein Video, ein Dashboard oder eine virtuelle Realität, als Lernobjekt (auch Launchable Object oder Tool) abstrahiert. Die anbietenden Server, welche Medien und Dienste für die Infrastruktur anbieten, fungieren als Service Provider und können ihre Angebote in der Middleware anmelden (publish / subscribe). Ein Launchable Object kann über die Schnittstellen der Middleware standardkonform angebunden und der Applikation bekannt gemacht werden. Das Objekt wird entsprechend nicht in ein anderes Server-System kopiert sondern direkt vom ursprünglichen Service Provider abgerufen.

Unterstützte Standards und angebotene Schnittstelle

Die Common Learning Middleware forciert die Datenstandardisierung und die Nutzung einheitlicher Datenbestände und Schnittstellen, welche dem sicheren aber interoperablen Datenaustausch dienen. So werden die Nutzenden (insbesondere Lernende) in den Mittelpunkt gestellt. Diese können unterbrechungsfrei auf Inhalte und Dienste verschiedener Anbieter zugreifen und ihre Daten mit diesen übergreifend teilen. Als Dienst stellt die CLM entsprechend Schnittstellen für eine dezentrale Anbindung unterschiedlicher Akteure zur Verfügung. Anbietende von Lerninhalten können ihre Angebote als Tool oder Service Provider an der Common Learning Middleware anmelden.

Grundliegende Funktionsweise der Common Learning Middleware | © Fraunhofer FOKUS

Der CLM Management Dienst ermöglicht es Institutionen, Angebote und Nutzenende zu verwalten. Für Letzteres muss kein neues Nutzungskonto in dem Dienst angelegt werden, sondern es wird auf einen der hinterlegten Single Sign-On Provider (bspw. Open ID Connect) oder Verzeichnisdienste (bspw. LDAP) zurückgegriffen um die Zugänge auf sichere Art wiederzuverwenden. Jedoch ist es auch möglich, ein neues Nutzungskonto im Management Dienst zu registrieren, wenn keine existierende Identität genutzt werden kann oder soll. Nutzungskonten können von den Bildungsverantwortlichen zu Kursen und Launchable Objects manuell oder automatisch zugeordnet („eingeschrieben“) werden. In Bezug auf die Lerninhalte gibt es pro Nutzungskonto unterschiedliche Rollen und Rechte. So kann ein Lehrender, sofern vom Lernobjekt ermöglicht, Anpassungen an den Lerninhalten vornehmen, ein Lernender hingegen kann nur die fertigen Inhalte abrufen.

Lerninhalte, -medien und -dienste können dann als Launchable Objects in die Applikationen für die Endnutzenden eingebunden werden. Hierbei erlaubt das Datenaustauschformat Common Cartridge den Austausch der didaktischen Struktur aller Lernobjekte, in die die Nutzenden jeweils eingeschrieben sind. Für das Einbinden von verknüpften Lernobjekten wird von der CLM, neben cmi5, die Spezifikation LTI (Learning Tools Interoperability in Version 1.1, 1.3 und Advantage) unterstützt. Es handelt sich hierbei um einen sicheren Aufruf (LTI Launch Request) von Lernobjekten und spiegelt das Vertrauensverhältnis zwischen einem sogenannten Tool Consumer oder Plattform (der Applikation für Endnutzende) und einem Tool oder Service Provider (dem Anbietenden der Lerninhalte) auf Basis etablierter Web-Standards wider. Ein Launchable Object enthält dabei entweder vorgerenderte HTML-Elemente oder inhaltliche Metadaten, welche dann von der Plattform geeignet dargestellt werden müssen. Bei einem Launch werden die erforderlichen Daten von der Plattform signiert – die CLM übernimmt die Signierung und ermöglicht der Plattform einen kleinstmöglichen Verwaltungsaufwand von LTI Konfigurationen. Zudem wird mit ADL cmi5 (Teil-Spezifikation von xAPI) ein weiterer „Launch“-Mechanismus unterstützt, welcher ebenso auf etablierten Web-Standards basiert. cmi5 verfolgt jedoch einen alternativen Ansatz bei dem die Anfragedaten nicht signiert werden, sondern es wird ein Token ausgetauscht, den die CLM zur Verfügung stellt.

Die CLM überprüft bei jeder Schnittstellen-Anfrage die Nutzerdaten und die damit verbundene Rolle und Zugriffsrechte. Bei einer „Launch“-Anfrage (also der Anfrage der Applikation ein Launchable Object für den Nutzenden zu präsentieren) werden die Anfragedaten mit den Benutzerinformationen signiert (LTI) bzw. dessen Token zugrunde gelegt (cmi5) und dem Launchable Object via Service Provider übermittelt. Die CLM ermöglicht es zudem, zwischen verschiedenen Launch-Mechanismen, wie LTI1.1, LTI1.3, LTI Adavantage und cmi5, zu übersetzen. Dadurch können Anbietende bspw. auch cmi5 Objekte zur Verfügung stellen und diese können als LTI Tool in einer bestimmten Version in die Applikationen geladen werden (bzw. vice versa).

Die Benutzerinteraktionsdaten (Learning Records) können in der Applikation oder in den jeweiligen Lernobjekten erfasst werden. Hierzu benötigt das Launchable Object die Nutzerinformationen – diese werden bei den beiden „Launch“ Mechanismen übermittelt. Für die Erfassung von Learning Records werden die Spezifikation Experience API (xAPI) von ADL und CALIPER unterstützt. Diese Learning Records können in Learning Record Stores (LRS) persitiert werden. Bildungsinstitutionen können eigene LRS an der CLM registrieren und einstellen, welche Nutzenden bei der Interaktion mit welchen Tools welche Art von Learning Records an welchen LRS schicken. Die CLM orchestriert und sichert das vertrauenswürdige Zusammenspiel zwischen Learning Record Provider (welche aus der Interaktion neue Learning Records produzieren), Learning Records Stores (als Datenbanken zur Verwaltung pseudonymisierter Interaktionsdaten) und Learning Record Consumer (welche gespeicherte Learning Records verarbeiten, bspw. KI-Dienste). Die CLM verwaltet die Berechtigungen von Diensten und deren Zugriffe auf die Learning Record Stores.

Sämtliche Schnittstellen der CLM sind RESTful APIs (Representational State Transfer Application Programming Interface) – Programmierschnittstellen nach dem Paradigma für Softwarearchitekturen von verteilten Systemen. Die Schnittstellen wurden nach der Spezifikation OpenAPI ausspezifiziert und dokumentiert und können von Entwicklern über eine OpenAPI konforme Benutzeroberfläche wie z. B. Swagger UI ausprobiert werden. Für relevante Schnittstellen, wie das Bereitstellen von LTI-basierten Tools als Tool Provider, wurden Validatoren implementiert, welche beim Einbinden neuer Lernobjekte an der CLM diese nach dessen Spezifikation validieren und gegebenenfalls auf Fehlkonfigurationen hinweisen.

CLM Management Dienst

Obwohl die Common Learning Middleware ein Mediator-Dienst ist, welcher sich hauptsächlich um die Verknüpfung von Instituten, Lernplattformen, Inhalten und Diensten kümmert, bringt dieser auch einen eigenen Management Dienst als modularen Teildienst zur Teilnehmendenverwaltung mit. Der Management Dienst ermöglicht die Nutzung eines Rollen- und Rechtekonzepts für die Verwaltung von verschiedenen beteiligten Institutionen (hier Mandanten genannt), Nutzenden, Diensten, Inhalten und erlaubt die Verwaltung von Nutzerrollen und deren Zugriffsrechten. Der CLM Management Dienst unterscheidet verschiedene Ebenen:

• Globale Administrations-Ebene: Auf dieser Ebene können die Betreibenden der Plattform globale Einstellungen vornehmen sowie Bildungsinstitutionen und Entwicklungszugriffe verwalten.
• Institutionelle Administrations-Ebene: Jede Institution kann eigene Inhalte und Dienste an-melden und verwalten, Nutzenden Rollen an den Diensten zuordnen und diese in einzelne Inhalte oder ganze Kurse einschreiben.
• Institutionelle Entwickler-Ebene: Jede Institution kann eine Reihe von technischen Schnittstellen (APIs) der CLM nutzen. Beispielsweise um eigene Inhalte oder Dienste der CLM bekannt zu machen (publish/subscribe), Endnutzende an ihren Applikationen über die CLM per Single Sign-On authentifizieren, Inhalte und Dienste in den eigenen Applikationen einladen oder Lern-Aktivitätsdaten (Learning Records) in separaten Learning Record Stores persistieren. Dafür werden von globalen Administrierenden Passwörter zur Benutzung der Schnittstellen (Development-Keys) an die entwickelnden Personen der Institutionen vergeben. Diese stellen sicher, dass nur berechtigte Entwickelnde die CLM und ihre Angebote nutzen können und dass bei einer schadhaften Verwendung (bspw. bei bestimmten Cyber-Attacken) die Nutzungsberechtigung für die Schnittstellen entzogen werden kann.
• Endnutzungs-Ebene: Endnutzende kommen nicht direkt in den Kontakt mit der Common Learning Middleware und nehmen diese in der Regel auch nicht wahr. Vielmehr nutzen sie eine App, Lernplattform/Lernmanagementsystem oder sonstige Benutzerschnittstellen, welche die Institutionen anbieten und an die CLM angebunden sind (diese werden hier der Einfachheit halber Lern-Applikation genannt). In dieser Applikation können die Nutzenden entweder eine der hinterlegten Single Sign-On Lösungen (bspw. OpenID Connect, LDAP) zum Login mit ihren existierenden Zugangsdaten nutzen oder ein neues Nutzungskonto am CLM-eigenen Management Dienst registrieren. Nach der Authentifizierung können die Nutzenden dann entsprechend den von den Institutionen hinterlegten Einschreibungen und Rollen auf die Inhalte und Dienste zugreifen.

Grafische Oberfläche des CLM Management Dienstes | © Fraunhofer FOKUS

Neben der grafischen Verwaltung von Nutzenden, Lernobjekten und Aktvititätsdaten bietet die CLM auch wichtige Funktionen für den Datenschutz an. Beispielsweise werden Ids der Nutzenden für jegliche Kommunikation mit externen Diensten (mittels eines Hashing-Algorithmus wie SHA-256 und eines Salts) pseudonymisiert. Die Zuordnung eines Pseudonyms funktioniert demnach nur in eine Richtung und es gibt keine Zuordnungstabelle: Mit Kenntnis der Id des Nutzenden (bspw. in der Applikation) kann die CLM das Pseudonym erstellen und dieses an die anderen Dienste zur weiteren Verarbeitung weitergeben. Aus dem Pseudonym an sich kann jedoch nicht auf die Id bzw. andere persönliche Daten geschlossen werden.

Das Management Dashboard dient der Visualisierung der anonymisierten Gesamtzahlen der aktuell angebunden Bildungsinstitionen, Nutzenden und deren Rollen, der Tool Provider und Tools sowie den täglichen anonymisierten Zahlen zu abgerufenen Tools und erzeugten Learning Records.