Technische Umsetzung
Webtop ist eine Java Servlet-Applikation, und die von uns daraus entwickelte Anwendung ist es auch. Sie läuft unter dem Java Servlet-Container Tomcat und unter Apache auf bis zu acht Applikations-Servern parallel.
Webtop bietet eine Reihe von Schnittstellen für Erweiterungen, die auch massiv genutzt werden mussten. Darüber hinaus war es notwendig, Module von Webtop zu ersetzen, weil sie zu wenig erweiterbar waren oder weil Fehler in der API vorlagen. Da der Quellcode von Webtop nicht vorlag, mussten einige Webtop-Module nachprogrammiert werden.
Das zentrale "WebtopServlet" nimmt alle Anfragen des Browsers entgegen, stellt unter Benutzung der neuen gemischten User/Pool Connection Policy die Datenbankverbindung bereit und steuert dann je nach Benutzeranfrage eine Aktion an. Die Aktion leitet dann entweder weiter an eine andere Aktion oder sie zeigt eine JSP-Seite an. Das Prinzip Model-View-Controller (MVC) ist durch diese Konzeption realisiert.
Besondere Herausforderungen
Eine der größten Herausforderungen im Projekt war die Implementierung des Features "History für Pool Connections".
Wenn die "History"-Funktionen von Webtop und dem Datenbank-Server genutzt werden sollen, sieht der Hersteller vor, dass die "User Connection Policy" benutzt werden muss, d.h. es existiert eine 1:1 Beziehung "Webtop Benutzer Session" und "Datenbank Verbindung". Nun sind Datenbank Verbindungen aber eine teure Ressource, daher entstand die Anforderung, einfache History-Funktionen wie "Suche verfeinern" - also Eingrenzen der Treffermenge der letzten Suche mit neuen Suchvorgaben - auch für Pool Connections zu ermöglichen.
Da sich alle Webtop-Funktionen, die sich auf frühere Treffermengen beziehen, auf die "History"-Funktion des Servers verlassen und diese nun nicht zu Verfügung stand, mussten die entsprechenden Funktionen nachprogrammiert werden.
Um die Funktionalität möglichst nahe um Original zu haben, wurde je Session eine "Query List"eingeführt, in der alle Anfragen des Benutzers "mitgeschnitten" werden. Abhängig von der Navigation des Benutzers (Blättern in Listen und Records, Springen zu anderen Datenbanken oder Ansichten etc.) wird diese "Query List" gepflegt. Jeder Datenbankzugriff wird, bevor er zum Server geschickt wird, daraufhin untersucht, ob er einen Bezug auf einen Record der History enthält. Ist das der Fall, so wird die "Query List" vom richtigen Ereignis an wieder "abgespielt" - die in der History der jeweiligen Datenbankverbindung fehlenden Einträge werden so unbemerkt vom Benutzer reproduziert und die aktuelle Anfrage wird so manipuliert, dass sie sich nun auf die gerade eben wieder erzeugten Resultate bezieht.
Weil an sich jede Benutzer-Aktion in Webtop eine eigene Datenbank-Abfrage auslöst, war diese Entwicklung im Hinblick auf die internen Abläufe sehr komplex. Trotzdem hat sie sich für den Kunden ausgezahlt.