IT-Architektur

CampusConnect nutzt eine lose, leichtgewichtige Architektur mit dem „E-Learning-Community-Server“ (ECS) als Message Oriented Middleware (MOM) mit REST-basierter Webservice-Schnittstelle, über die JSON-Ressourcen ausgetauscht werden.

Die angebundenen Systeme (sog. „Teilnehmer“ oder „Participants“) sind allein dem ECS bekannt, in dem die Systeme verwaltet werden. Die Kommunikation zwischen ECS und Participanten erfolgt verschlüsselt, wahlweise abgesichert über Serverzertifikate (hierfür ist der Betrieb einer eigenen CA nötig) oder Nutzername/Passwort-Eintrag. Die angebundenen Systeme nutzen dafür einen Konnektor, der entweder im System integriert ist (z.B. ILIAS) oder als Plugin installiert werden kann (z.B. Moodle und Stud.IP).

Im ECS sind die Participanten zu sog. Communities zusammengefasst. Jeder Participant kann dabei beliebig vielen Communities angehören. Im CampusConnect-Administrationsbereich des Participanten kann der Systemadministrator festlegen, mit welchen Participanten der Communities seine Hochschule welche Daten austauschen möchte. Jeder Participant sieht dabei nur die Communities, denen er selbst angehört. Es kann also auch hochschulinterne Communities geben, von deren Existenz die auswärtigen Systeme gar nichts mitbekommen.

Ein Dozent kann dann Kurse für ein oder mehrere Systeme anderer Hochschulen freigeben, die sein Systemadministrator zugelassen hat. Wenn ein Dozent dies tut, wird eine Courselink-Ressource, welche Metadaten zur Veranstaltung enthält, an den ECS geschickt. Von dort holen sich die Systeme, für die der Kurs freigegeben ist, diese Informationen, indem sie in regelmäßigen Abständen beim ECS nachfragen, ob es neue Mitteilungen für sie gibt. Der ECS selbst bleibt also in dieser Architektur immer passiv: er bekommt Mitteilungen von den Systemen und die Systeme holen Informationen beim ECS ab. So entsteht keinerlei Firewallproblematik. Die Systeme, für welche ein Kurs freigegeben worden ist, erstellen aus den Daten „Kurslinks“, das heißt Kursobjekte, die als Link fungieren.

Klickt ein Student auf einen solchen Kurslink, schickt seine Lernplattform einen Hashtoken, der aus seinen Nutzerdaten gebildet wird, an den ECS und der Student gelangt über einen Redirect zu kursanbietenden Plattform. An die URL sind die personenbezogenen Daten des Nutzers angehängt. Die kursanbietende Lernplattform bildet aus diesen Daten einen Hash und vergleicht das Ergebnis mit dem auf dem ECS abgelegten Token. Ist es identisch (das ist der Regelfall; ansonsten hätte der Nutzer die Daten in seinem Browser manipuliert), lässt sie den Nutzer bei sich zu. Das System erstellt einen Nutzeraccount, mit welchem der Nutzer sich am freigegebenen Kurs anmelden kann.

Der Nutzer mit einem solchen Account kann sich nicht direkt an den fremden Lernplattformen anmelden, sondern muss immer in der Heimatplattform eingeloggt sein. Für Systeme, die in einer Shibbolethföderation erreichbar sind, lässt sich der Tokenmechanismus über den ECS deaktivieren. In diesem Fall würde nur die Kursfreigabe als Information genutzt, welche Kurse für die Studierenden anderer Hochschulen verfügbar sind.

Von Stud.IP aus ist es auch möglich, dass ein Dozent von seinem Kurs aus e inen Kurs in ILIAS oder Moodle anlegt. In diesem Fall werden die Ressourcen „courses“ und „course_members“ verschickt. Die Zielplattformen erzeugen aus diesen Daten ein Kursobjekt mit einer Mitgliederverwaltung und senden die URL zu diesem Kurs an Stud.IP zurück. Über diese URL gelangen die Studenten von Stud.IP aus zum Kurs in ILIAS oder Moodle. Damit dieses Szenario funktioniert, ist darauf zu achten, dass Stud.IP in der „course_members“-Ressource dasselbe personenidentifizierende Attribut verwendet, wie es sie dem Nutzer an den Link angehängt mitgibt.

Auch bei der Anbindung von Campusmanagementsystemen an Lernplattformen werden die Ressourcen „courses“ und „course_members“ verschickt und in der Lernplattform zu Kursen verarbeitet. Bislang ist der Regelfall, dass die Schnittstelle von CampusConnect nicht direkt im Campusmanagementsystem integriert ist. Vielmehr ist dem Campusmanagementsystem ein Proxy vorgeschaltet, der mit diesem kommuniziert, wie es das Campusmanagementsystem vorsieht, und die Daten für die Ressourcen und das Messaging der REST-Schnittstelle von CampusConnect aufbereitet. Neben Kursen können in diesem Szenario auch Verzeichnisstrukturen übertragen werden, in welche die Kurse in der Lernplattform eingefügt werden.

Es ist eine Konfigurationsfrage des CMS-Proxys und des ECS, ob die „course_members“-Ressource über den ECS geschickt oder direkt vom CMS-Proxy an die Lernplattform geschickt wird. Über den ECS erfolgt in diesem Fall lediglich das Messaging. So wie beim Authentifikationsverfahren über den Token werden also keine personenbezogenen Daten über den ECS verschickt und dort zwischengespeichert. Dadurch ist der ECS geeignet hochschulübergreifend geneutzt zu werden.

Zum Seitenanfang