-
Notifications
You must be signed in to change notification settings - Fork 3
Home
Das System wurde 2013 vordergründig durch die Martin-Luther-Universität Halle-Wittenberg als Folgesystem einer bis dahin bestehenden Plattform entwickelt, zur Verwaltung von Übungsaufgaben, Übungsgruppen und Einsendungsbewertungen. Dabei begreift sich das System nicht als umfangreiche Lernplattform, sondern eher als Übungsverwaltung.
Zudem profitiert das System von der langjährigen Erfahrung, auf diesem Gebiet, sodass von Anfang an eine modulare Entwicklung im Vordergrund stand. Die Betreuung und Weiterentwicklung erfolgt dabei durch wechselnde Mithelfende und langfristig eher sporadisch, sodass die verwendeten Technologien auf einen längeren wartungsfreien Betrieb abzielen.
C: das Schichtenmodell von OSTEPU
Das System unterteilt seine Bestandteile dabei zunächst logisch, wie in Abbildung C dargestellt, innerhalb einer Schichtenarchitektur, welche eigene Entwicklungsgruppen darstellen und damit durchaus unterschiedlich in ihrer konkreten Umsetzung sind.
Ein großer Teil der inneren Logik besteht dabei aus voneinander getrennten Mikroservices, welche eine feste, klar abgegrenzte Aufgabe erledigen, sodass größere Aufgaben, wie in Abbildung D dargestellt, durch die Verschaltung kleinerer Module erledigt werden.
D: die Bearbeitung einer Aufgabe in OSTEPU
Die Kommunikation zwischen den Komponenten basiert auf einer REST-Schnittstelle. Dadurch ist die interne Schnittstelle identisch zur äußeren. Dabei kommunizieren die Komponenten auf dem Server von OSTEPU also gleichermaßen mit externen Komponenten, sodass wir diese prinzipiell auch für die Kommunikation zwischen OSTEPU und eines anderen Service verwenden können.
Wir wollen nun ein kleines Beispiel für eine lesende GET
Anfrage betrachten.
Dazu wollen wir die Daten des Nutzers mit der userId=1
ermittelt. Die zuständige Komponente wäre dabei die Datenbankkomponente DBUser
, welche die Adresse http://localhost/ostepu/DB/DBUser
besitzt. Wir können dort nun unsere eigentliche Anfrage user/user/1
stellen. Dabei hat dieser Abfrageteil den Aufbau Rückgabetyp/Bedingung/Wert
.
Die konkrete Anfrage sieht dann wie nachfolgend aus.
GET http://localhost/ostepu/DB/DBUser/user/user/1
Die Antwort der Komponente erfolgt dann mithilfe von HTTP-Statuscodes und durch JSON kodierte Inhalte.
{
"id": "1",
"userName": "till",
"email": "till@email.de",
"firstName": "Till",
"lastName": "Uhlig",
"flag": "2",
"password": "9f86d081884c7d6...",
"failedLogins": "17",
"courses": [{
"status": "3",
"course": {
"id": "1",
"name": "Bengalisch II",
"semester": "SS 11",
"defaultGroupSize": "1"
}
}]
}
C: ein JSON kodiertes Nutzerobjekt
Die Abbildung C zeigt nun jene Antwort unserer zuvor gestellten Anfrage für die Daten des Nutzers mit der userId=1
. Dabei wurde hier zur Vereinfachung nur der Antwortkörper angegeben.