AGSS:Webinterface

Aus AGSS
Zur Navigation springen Zur Suche springen


Basisplattform für Webinterface[Bearbeiten]

Da die zentralen Anforderungen für alle Schulserver identisch sind, bietet sich eine Kooperation auf Basis-Ebene für die Entwickler geradezu an.

Hierzu evtl. interessant:

SAGA => kommender EU-Standard, der XML auf API-Ebene preferiert (siehe u.a.:

OSGI => development of new and exciting services and applications for the latest generation of networked devices. Wird u.a. auf von der Eclipse Foundation unterstützt. (siehe u.a.:


Andreas:

  • suad sollte nicht "aufgeblasen" werden, sondern eher modularisiert werden.

API: gemeinsam definieren => let's create a new Schoolserver Standard

Präsentation über die mögliche Struktur[Bearbeiten]

==> Präsentation von PG über die mögliche Struktur.


Hintergründe:

  • Skalierung soll möglich sein

=> wenn die Konfiguration auf dem zentralen LDAP-Server geändert wird, muss diese Änderung an die Server weitergeleitet werden, die davon betroffen sind

  • Frontend - unabhängig

=> Das Frontend soll nur über die API mit dem System kommunizieren. Damit wären später verschiedenste Frontends zur Administration des Schulservers möglich. Das reicht von reinen Webfrontends bis hin zum angepassten "Sysadmin-Menü" von Arktur oder reinen QT-Applikationen, die nativ auf dem Client laufen. Das Frontend sollte eine gewisse eigenintelligenz besitzen, um Daten zu validieren und den Nutzer zu führen. Die eigentliche Logik wird aber vom "Core-System" übernommen, das über die API angesteuert wird.

  • Sicherheit

=> Durch die Trennung von Core und Frontend ist schon einmal nicht alles erreichbar. Während die Fronends einfach die API bemühen, stellt das Core-System die Berechtigungen und die Validierung sicher.

  • Erweiterbarkeit/ Flexibilität

=> über Plugins sollte es möglich sein, das Core-System mit bestimmten Features zu erweitern. Diese Plugins sollten aber auf bestimmte Core-Funktionen wie z.B. die Authentifizierung, Lesen/ Schreiben von Dateien, (Neu)Starten und Stoppen von Diensten, etc. zurückgreifen könnnen. Damit sollte es später leicht sein, ein "eigenes" Plugin zu schreiben welches bestimmte Aufgaben übernimmt. Beispiele: Webmin, YaST.

  • Ob die Frontends mit der API über XML kommunizieren wäre zu diskutieren. Ebenso, ob die Plugins mit dem Core-System über XML kommunizieren. Hier klang ein wenig "Angst" vor einer neuen Unbekannten

durch. Allerdings würde XML hier nur zur Kapselung der Daten und Befehle dienen, was auf lange Sicht Vorteile bringen kann.

Beispiel:

 my $obj = NEW user (Name, Vorname, Klasse, ID);

==> dies geht in der "bisherigen" Version als Datenstring übers Netz:

 create - Name - Vorname - Klasse - ID

==> in XML gekapselt:

<command>create</command>
<name>Name</name>
<surname>Vorname</surname>
<class>Klasse</class>
<uid>ID</uid>

Auf den ersten Blick sieht das nur nach einem größeren Datenwulst aus - aber selbst hier sollte schon erkennbar sein, dass "Sonderzeichen", größere Arrays, etc. hier keine Probleme bereiten, weil die API klar erkennen kann, wann ein Objekt anfängt und endet.

Noch interessanter wird es, wenn plötzlich das Core-System oder das Frontend aktualisiert wird und neue Objekte beherrscht:

 create - Name - Vorname - Klasse - defaultRights - ID

=> Damit gibt es Probleme, weil Frontend und Core-System nicht mehr zueinander kompatibel sind. Mit der XML-Übermittlung ist es jedoch Problemlos:

<command>create</command>
<name>Name</name>
<surname>Vorname</surname>
<class>Klasse</class>
<defaultRights>defaultRights</defaultRights>
<uid>ID</uid>

==> Das Frontend (oder das Core-System - je nachdem was "älter ist") interessieren die neuen Objekte nicht - Sie werden einfach ignoriert. Um Problemen vorzubeugen muss hier eine DTD (http://de.wikipedia.org/wiki/DTD) definiert werden und die Tools übermitteln dann zusätzlich zu den obigen Settings die DTD-Version, nach der Sie die Daten übermitteln. Gibt es einmal inkompatible Änderungen in der DTD, kann so rechtzeitig gehandelt werden.

Nachteil: Die Frontends benötigen für die "Kapselung der Daten in XML" zwar ein weiteres Modul, welches dann aus obigem "NEW user(Name, Vorname, Klasse, ID)" ein entsprechendes XML-Konstrukt erzeugt und an die API übermittelt - die Vorteile dieses Verfahrens sollten aber diesen Nachteil überwiegen.

Weiterer Vorteil: Dank genormter DTD (API) könnten Schulbuchverlage und Softwareanbieter ihre Software so anpassen, dass diese "Schulserver-Konformität" bietet. Dank Datenhaltung im LDAP und genormter Schnittstellen um an diese Daten heran zu kommen fällt es sicherlich manchem Softwareanbieter leichter, entsprechende Schnittstellen in seine Software zu integrieren. Immerhin könnten seine Applikationen so auf einfach Art und Weise "Webtauglich" bzw. "Mutliplatform"-Tauglich werden.