Kurz zum Hintergrund:
Hibernate kapselt Datenbank-Persistenz von der Anwendungslogik. Somit sind keine Low-Level-Datenbankoperationen mehr nötig, die entsprechenden SQL-Statements werden von Hibernate erzeugt. Im Hintergrund öffnet Hibernate die Verbindung zur DB, schickt Statements und stößt die Ausführung an (commit), dies alles im Kontext einer „Session“. Die Erzeugung einer Session ist keine teuere Operation, es wird in der Hibernate-Literatur empfohlen, möglichst kurze Sessions zu verwenden und bei Bedarf neue zu erzeugen.
In der ersten Implementierung der Veranstaltungsverwaltung gab es (sehr schlecht!!) nur eine Session pro Sitzung, d.h. beim Login wurde eine Session erzeugt, die erst bei der Abmeldung wieder freigegeben wurde. Um das Session-Objekt von den Objekten anderer angemeldeter Teilnehmer abzuschotten, wurde es als ThreadLocal an den aktuellen Thread gebunden. Folge war, dass in bestimmten Konstellationen Domänenobjekte veraltete Daten gespeichert hatten, denn ein neuer Request eines Browsers kann in einem anderen Thread abgesetzt werden als bisher.
Inzwischen ist ein Session-Per-Request implementiert, das heißt, dass für jeden Aufruf einer Seite eine neue Session erzeugt wird, die nach erfolgreichem Laden committed und beendet wird. Dies hat jedoch Auswirkungen:

• Änderungen an der Datenbank (Update, Insert) werden erst ausgeführt, nachdem ein commit() auf die Transaktion der Session aufgerufen wurde. Bei Session-Per-Request kommt dieses commit eigentlich zu spät, nämlich erst nach der Darstellung des Inhalts der Seite. Daher muss das commit() bei Änderungsaktionen explizit angestoßen werden.
• Objekte, die nicht an eine Session gebunden sind, verursachen Fehler, sobald sie auf ihre Felder zugreifen wollen (Hibernates Lazy Loading – DB-Aktionen werden erst ausgeführt, wenn das Objekt tatsächlich benötigt wird, an sich eine gute Sache) oder selbst wieder persistiert werden sollen („Hibernate: no session or session was closed“). Auch auf solche Fälle muss daher in Zukunft sorgfältig geachtet werden.

In der Veranstaltungsverwaltung wird es zwei Arten von Heuristiken geben. Zum einen Heuristiken bei denen der Teilnehmer direkt für eine Veranstaltung oder einen Termin angemeldet wird und zum anderen Heuristiken bei denen alle Teilnehmer erstmal auf eine Warteliste kommen und die vorhandenen Plätze zu einem Zeitpunkt, anhand bestimmter Kriterien verteilt werden.
Für den Start der Veranstaltungsverwaltung sind erstmal die folgenden Heuristiken geplant. Bei diesen beiden Heuristiken werden die Anmeldungen direkt durchgeführt.

• First-Come-First-Served (FCFS)
• Automatische Gleichverteilung (Round-Robin)

First-Come-First-Served: Bei dieser Heuristik kann der Teilnehmer einen konkreten Termin der Veranstaltung wählen und sich für diesen anmelden. Dabei wird er sofort auf der Teilnehmerliste eingetragen, außer der gewählte Termin ist bereits belegt. In diesem Fall erscheint ein Warnhinweis mit der Option sich für diesen Termin auf eine Warteliste einzutragen.
Automatische Gleichverteilung: Hier werden die Anmeldungen nach Eingang direkt auf die einzelnen Termine verteilt. Dabei wird zunächst jeder Kurs mit einem Teilnehmer befüllt, dann mit einem zweiten und so weiter, bis alle Kurse voll sind. Weitere Anmeldungen kommen auf eine Warteliste für die Veranstaltung.
 
In zukünftigen Versionen der Veranstaltungsverwaltung werden dann weitere Heuristiken zur Verfügung stehen. Unter anderen werden das die Folgenden sein.
Losverfahren: Beim Losverfahren werden alle Anmeldungen gesammelt und zu einem festen Zeitpunkt werden aus diesen die Kursteilnehmer per Zufall ermittelt und dann verteilt. Auch hier gibt es die Option die nichtberücksichtigten Anmeldungen auf einer Warteliste zu hinterlegen.
Equal Balancing: Die Anmeldung bereits stark ausgelasteter Termine wird solange geschlossen, bis weniger ausgelastete Termine „aufgeholt“ haben.
Präferenzauswahl: Die Anmeldungen werden gesammelt und bei jeder Anmeldung sind drei Termine mit entsprechender Präferenz (1-3) anzugeben. Nach Anmeldeschluss versucht die Heuristik eine Verteilung zu finden, so dass möglichst viele Erst- und Zweitpräferenzen berücksichtigt werden.

Die Veranstaltungsverwaltung wurde von uns in zwei Komponenten aufgeteilt. Die Komponente vv-core ist für das Backend der Veranstaltungsverwaltung zuständig und die Komponente vv-web für das Frontend. Neben diesen beiden Komponenten gibt es noch weitere, die für bestimmte Aufgaben innerhalb der Veranstaltungsverwaltung zuständig sind.
Die Aufgaben der Backendkomponente vv-core umfassen hauptsächlich die folgenden Bereiche:

• Import aller anmeldbaren Veranstaltungen und ihrer Kurse von UnivIS in die Veranstaltungsverwaltung.
• Anbindung an die Datenbanken der Veranstaltungsverwaltung und von mein campus. Aus der Datenbank von mein campus bezieht die Veranstaltungsverwaltung alle Daten die Dozenten und Studenten betreffen. In der eigenen Datenbank werden die von UnivIS importierten Veranstaltungen und Kurse sowie ihre „Teilnehmer“ gespeichert.
• Entwicklung der Heuristiken für die Anmeldung. Mit dem Start der VV kommen mindestens die beiden Heuristiken First-Come-First Served und die Gleichverteilung in Kurse.
• Verwaltungsaufgaben, wie z.B. dem Überprüfen von Nutzerrechten für geplante Aktionen.

Im Frontend vv-web laufen alle Fäden zusammen. Alle anderen Komponenten, auch der vv-core, werden hier eingebunden um ihre Funktionalitäten zu nutzen. Weiterhin werden in dieser Komponente alle Webseiten der Veranstaltungsverwaltung generiert. Um z.B. die Übersichtsseite aller angemeldeten Teilnehmer einer Veranstaltung zu generieren, werden alle benötigten Daten aus dem vv-core abgerufen. Die Präsentation, z.B. in Tabellenform, erfolgt mittels vorgefertigter Elemente des vv-webs. Das aus mein campus bekannte Layout, wurde für die Veranstaltungsverwaltung in eine eigene Komponente ausgegliedert und wird auf jeder erzeugten Webseite eingebunden.

In der Veranstaltungsverwaltung durchlaufen Veranstaltungen und Kurse ein Lebenszyklus-Modell. Dieses ist nötig um bestimmten Nutzergruppen in den unterschiedlichen Phasen des Modells den Zugriff auf Aktionen zu ermöglichen oder diesen zu verweigern. Diese Phasen des Lebenzyklus wurden wie folgt eingeteilt:
LifeCycleState = {PUBLISHED, REGISTRATION_PERIOD, DISTRIBUTION_PERIOD, RUNNING_PERIOD, FINISHED}
PUBLISHED: Eine Veranstaltung die von dem Dozenten ins UnivIS eingestellt und in die Veranstaltungsverwaltung importiert wurde. Wärend dieser Phase sieht der Student die Veranstaltung, mit allen Informationen, kann aber noch keine Aktionen tätigen.
Mit Beginn des Anmeldezeitraum ändert sich der Lebenszyklus automatisch zu REGISTRATION_PERIOD. Studenten können sich nun anmelden und Dozenten erhalten einen Überblick wie stark die Veranstaltung ausgelastet ist.
Nach dem Ende des Anmeldezeitraums wird die Phase DISTRIBUTION_PERIOD aktiv. In dieser Phase werden die Teilnehmer mittels der gewählten Heuristik automatisch der Veranstaltung oder, falls die Veranstaltung Kurse hat, einem Kurs zugeordnet. Nach dieser Zuordnung geht eine Email an alle angemeldeten Studenten mit ihrem Status.
Während der Durchführung der Veranstaltung befindet sich diese in der Phase RUNNING_PERIOD. Da sich Studenten evtl. für unterschiedliche Veranstaltungen angemeldet haben und dadurch Terminüberschneidungen möglich sind, können sich Studenten in dieser Phase noch abmelden. Dozenten können dann den freien Platz durch einen Nachrücker von der Warteliste auffüllen.
Nach Beendigung der Veranstaltung bekommt die Veranstaltung die Phase FINISHED. Alle Aktionen, mit Ausnahme der Benachrichtigungsfunktion, sind nun für die verschiedenen Benutzergruppen gesperrt. Dozenten können sich zusätzlich noch die Teilnehmerlisten ausdrucken.

Bei der Konzeption der  Veranstaltungs-Anmeldung dachten wir zunächst daran, dass es eine Teilnehmerliste und eventuell eine Warteliste pro Veranstaltung geben geben sollte. Dies erwies sich jedoch bald als zu unflexibel:
Was zum Bespiel tun bei Anmeldeheuristiken wie RoundRobin? Hier meldet man sich für einen Course an, die Zuteilung zu einem bestimmten Track (zu diesen Begriffen siehe meinen letzen Blogpost) erfolgt aber durch das System. Ähnlich bei Losverfahren bei einem Course mit Tracks. Hier resultiert die Anmeldung darin, dass der Angemeldete zunächst in einer virtuellen Warteliste des Courses gespeichert ist; erst wenn die Verlosung der Plätze durchgeführt wird, erfolgt die Verteilung auf einzelne Tracks – die selbst aber keine Warteliste haben.
Wir haben uns für ein Subscription-Objekt entschieden, in dem die Verbindung zwischen Teilnehmer und Veranstaltung gespeichert wird:
Subscription(Course course, Track track, Participant participant, Subscriptiontype type)
Subscriptiontype := {SUBSCRIBED|WAITINGLIST|UNSUBSCRIBED}
Eine Veranstaltung hat somit eine Liste aus Subscriptions und über deren Type kann Teilnehmer- und Warteliste dynamisch extrahiert werden.
Also, wie im Titel des Posts: Eine Veranstaltung hat keine Teilnehmer, sondern Subscriptions mit Subscriptiontype=SUBSCRIBED
 

Die übliche Ausprägung einer Veranstaltung an einer Universität (egal ob Vorlesung, Übung, Seminar oder sonstiges) ist:

• ein Veranstaltungsname
• eine bestimmte Zeit und ein Ort für die Durchführung
• ein Dozent

Jeder kennt jedoch Veranstaltungen, die wegen hoher Teilnehmerzahlen aufgeteilt werden – beispielsweise eine Übung im Grundstudium Informatik mit hunderten von Teilnehmern, bei der jede Übungsgruppe jedoch eine Maximalzahl an Teilnehmern hat. Als Student muss man nur eine der Ausprägungen besuchen, also zum Beispiel die Übung montags 14:00 bis 16:00 Uhr.
Die UnivIS-Nomenklatur hierfür ist „Veranstaltung“ und „Kurs“. Das heißt, eine Veranstaltung kann – muss aber nicht – mehrere untergeordnete Kurse haben. Der Besuch eines dieser Kurse bedeutet den Besuch der Veranstaltung.
Die Veranstaltungsverwaltung bildet diese Struktur natürlich ebenfalls ab, allerdings mit englischen Bezeichnern:

• UnivIS-Veranstaltung = Course
• UnivIS-Kurs = Track

Wegen der phonetischen Ähnlichkeit von „Course“ und „Kurs“ ist es geboten, sich an eine der Nomenklaturen zu halten und dies vor dem Gespräch abzuklären.
Ein Track erbt von seinem Course einige Stammdaten wie die Zuordnung zu einem Studiengangsmodul oder die Anzahl der Credits, die bei erfolgreichem Besuch vergeben werden. Tracks eines Courses können sich jedoch unterscheiden in Bezug auf

• Dozenten
• Zeit und Ort
• und natürlich unterscheiden sie sich durch die Teilnehmer, es sei denn, ein Student möchte doppelte Arbeit leisten 😉