Tracking-Info
Blog

+49 - 511 - 270 416 0

info@aldebaran.de

Referenzprojekt Softwareentwicklung

Web Frontend als Java Servlet Anwendung mit JSP und Java Script

für die Artikel- und Fakten-Datenbank eines der größten deutschen Verlage in Hamburg in Zusammenarbeit mit Syncope Communications GmbH, Hamburg

Hintergrund

Webfrontend Webtop als Java-Servlet

Die seit den 80er Jahren existierende Artikel-Datenbank mit allen Publikationen des Verlags und zugekauften weiteren Veröffentlichungen hat ein neues Web-basiertes Frontend bekommen.

Der Hersteller des Datenbank-Backends lieferte den Web-Datenbank-Browser "Webtop", der als Plattform für die Anwendung dient.

Eine ganze Reihe von Anforderungen mussten durch Ergänzen, Ersetzen oder durch Erstellen neuer Zusatzmodule erfüllt werden.

Der eingesetzte Datenbank-Server ist auf Volltextrecherchen spezialisiert und hat einen immensen Funktionsumfang für diese Zwecke.

Dazu gehört auch eine "History"-Funktion: Einmal gefundene Treffermengen bleiben im Zugriff und können durch spezielle Kommandos mit späteren Suchanfragen kombiniert werden. Diese "History" existiert je Datenbankverbindung. So lange der Benutzer die Verbindung nicht trennt, bleibt sie erhalten.

Aufgrund der Lizenzpolitik des Herstellers sind Datenbankverbindungen eine teure Ressource. Deshalb kann man "Webtop" so einstellen, dass er je Benutzer-Session eine Datenbankverbindung behält ("User Connection Policy" – das ermöglicht die History-Funktion) – oder so, dass alle Datenbankverbindungen gemeinsam genutzt werden ("Pool Connection Policy" – damit entfallen die History-Funktionen, weil man bei der nächsten Anfrage wahrscheinlich eine andere Datenbankverbindung bekommt).

Zu den Anforderungen und gelieferten Lösungen gehörten:

Generell

Den Kunden in die Lage zu versetzen, selbst Änderungen vorzunehmen. Die gesamte Anwendungsentwicklung wurde unter der Prämisse durchgeführt, dass der Kunde selbst Änderungen an der Darstellung vornehmen, aber auch Funktionen ändern und ergänzen kann. Offenheit, Dokumentation und Workshops ermöglichten es ihm, die Anwendung selber weiter zu entwickeln. Durch das Ziehen einer klaren Grenze der Zuständigkeiten konnten dabei Reibungsverluste zwischen Entwicklung durch uns und den Kunden weitgehend vermieden werden.

Backend

  • Realisierung eines verlässlichen Logging für Abrechnungs-, Mess- und Debug-Zwecke
  • Konfiguration zur Laufzeit, z.B. bei Ausfall oder Hinzufügen eines Datenbank-Servers, ohne Neustart des Systems
  • Ermöglichen von gemischtem User Connection- und Pool Connection-Betrieb, der in Webtop nicht vorgesehen ist; hierzu wurde eine eigene Datenbankverbindungs-Verwaltung entwickelt und die von Webtop gelieferten Module damit ersetzt.
  • Eingeschränkte Nachbildung von Datenbank Server "History"-Funktionen für Benutzer mit Pool Connection
  • Database Backend Load Balancing: Ein Benutzergruppen-abhängiges Load Balancing für Datenbank-Server wurde innerhalb der Anwendung realisiert.

Darstellung

  • Applicaton Views: Realisierung verschiedener Benutzergruppen mit verschiedenen Funktionsumfängen und verschiedenen Rechten, Ressourcen zu verbrauchen, abhängig von Login Name und IP Nummer
  • Darstellung von XML-Dokumenten mit XSL-Transformation
  • Vermeidung von Redundanz bei der Realisierung der Darstellung bei rund 30 ähnlichen Ansichten durch objektorientierte Aufteilung des dargestellten Bereichs in Regionen
  • Navigation im Frameset mit Interaktion zwischen JavaScript-Fragmenten und der Java Servlet-Session
  • JSP Tag Library zur Kapselung von komplexen, wiederkehrenden JavaScript- oder HTML-Fragmenten

Erweiterung des Funktionsumfangs

  • Sammeldruck – ausgewählte Fundstellen markieren, auch über mehrere Recherchen hinweg, und zusammen anzeigen und drucken
  • Verknüpfung der verschiedenen Datenbanken: Querverweise z.B. von Vorgangs- zu Artikeldatenbank und zurück
  • Aufteilung der Suchmasken in "einfache" und "erweiterte" Suche
  • Erweiterungen in den von Webtop verarbeitbaren Suchmöglichkeiten: Volltextsuchen "innerhalb n Worten" wurden ermöglicht, komfortable Eingabemöglichkeiten für Datum- und Zeitangaben und von Suchoperatoren wurden entwickelt.

Technische Umsetzung

Struktur der Artikel- und Faktendatenbank
Struktur der Artikel- und Faktendatenbank

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.

Verwandte Links