Migration der Java-Webanwendungen

Bei allen Java-Webanwendungen haben wir das Problem, dass sie auf dem stark in die Jahre gekommenen Framework Grails 2.3 basieren. Moderne Technik funktioniert damit nicht. Außerdem war es schon immer schwierig, Entwickler für die etwas gewöhnungsbedürftige Kombination von Groovy und Java zu finden. Daher will ich auf eine reine Java-Implementierung migrieren – unter Nutzung gängiger Java-Frameworks wie Spring Boot, Hibernate, Thymeleaf etc.

Java-Webanwendungen bestehen typischerweise aus vier Schichten: Model, Service, Controller, View. Bei modernen Softwarearchitekturen setzt man oft den View in Javascript um (z.B. mit Angular oder Vue.js) und kommuniziert über eine REST-Schnittstelle mit den Controllern. Da ich aber nicht zu viel auf einmal umbauen will, bleibe ich bei serverseitigen Views mit Thymeleaf.

GOV

Das Geschichtliche Ortsverzeichnis (GOV) ist eine der Java-Webanwendungen, bei denen die Umstellung schon gut vorangekommen ist. Das komplette Model, die meisten Services und ein großer Teil der Controller sind bereits migriert. Die SOAP-Webservices des GOV sind bereits voll funktionsfähig.

Ebenfalls fertig ist die Erzeugung des Mini-GOV, die nun komplett ohne händischen Eingriff durchläuft. Hier fehlt noch ein Cronjob, der die Erzeugung jeden Monat oder sogar jede Woche anstößt.

Zuletzt habe ich daran gearbeitet, die Toponymresolution wieder gängig zu machen. Bei der Toponymresolution geht es darum, aus Ortsnamen möglichst passende Treffer im GOV zu finden. Diese Funktionalität stammt aus einer Masterarbeit, die ich vor einigen Jahren betreut habe. Sie schlummerte schon seit einiger Zeit im GOV, funktionierte aber noch nie vernünftig.

Unter https://gov-dev.genealogy.net läuft ein Testsystem, das lesend auf die Produktivdatenbank zugreift. Der Quellcode ist hier zu finden: https://gitlab.genealogy.net/project/gov/tree/spring

DES

Auch die Migration des Daten-Eingabe-System (DES) ist weit fortgeschritten. Das komplette Model, die meisten Services und ein großer Teil der Controller sind bereits migriert. Es fehlen jedoch noch einige Views, insbesondere im Admin-Bereich. Auch hierfür gibt es ein Testsystem, das aus Sicherheitsgründen nur lesend auf die Produktivdatenbank zugreifen darf: https://des-dev.genealogy.net. Aufgrund des bisher aus nur lesenden Zugriffs funktionieren aber dort (gewollt) viele Dinge nicht. Der Quellcode ist hier zu finden: https://gitlab.genealogy.net/project/des

Weitere Webanwendungen

Auch die Metasuche und GEDBAS können migriert werden. Da hier aber keine inhaltlichen Weiterentwicklungen anstehen, ist die Migration hier nicht ganz so dringend. Bei GEDBAS habe ich auch schon angefangen, Model und die meisten Services sind umgebaut.

gedbas4all

gedbas4all soll auf Basis von Wikibase neu aufgebaut werden. In dem Zusammenhang gibt es mehrere Handlungsstränge:

Installation von Wikibase

Wir brauchen für gedbas4all eine Wikibase-Installation einschließlich SPARQL-Endpunkt. Dafür ein ich eine docker-compose-Datei geschrieben, die unter https://gitlab.genealogy.net/jzedlitz/gedbas4all-wikibase zu finden ist. Derzeit gibt es noch zwei Instanzen. gedbas-test.genealogy.net für genealogische und prosopographische Daten und gov-test.genealogy.net als Kopie des GOV. Es scheint aber sinnvoller zu sein, beides in nur einer Wikibase-Instanz zusammenzuführen. An dieser Stelle ist Erfahrung in Systemadministration (z.B. mit Docker und Træfik) gefragt.

Schneller Import

Der Datenimport von Wikibase ist sehr langsam; das Einfügen unserer gut 20 Millionen Daten aus dem DES würde Wochen dauern. Daher habe ich ein Programm geschrieben, das viel schneller Daten in Wikibase einfügen kann. Der Quellcode ist Teil von gedbas4all-wikibase-import.

DES Rohdaten

In der gedbas4all-Entwicklergruppe haben wir bereits überlegt, wie sich Rohdaten aus dem DES in gedbas4all/Wikibase darstellen lassen. Ein Programm liest neu im DES eingegebene Daten und schreibt dafür Einträge in gedbas4all. Der Quellcode ist Teil von gedbas4all-wikibase-import.

Import der Adressbuch-Daten

Die bisher bereits in gedbas4all vorhandenen Adressbuch-Daten müssen für das neue gebas4all mit Wikibase-Fundament aufbereitet werden. Dafür gibt es in gedbas4all-wikibase-import bereits Code, der Daten aus den offline erfassten Originaltabellen in Wikibase-Einträge umformen kann. Eine Herausforderung ist, dass dies mit den über das DES eingegebenen Daten kompatibel sein muss. Warum wird aus den Originaltabellen eingelesen? Es hat sich herausgestellt, dass viele der Daten unseren Qualitätsansprüchen nicht genügen. Daher ist eine manuelle Überarbeitung notwendig. Meist werden die Probleme erst durch einen Blick in die Originaltabellen sichtbar. Auch Vergleiche mit heute online verfügbaren Scans offenbaren so manche Schwäche in den abgetippten Daten.

DES → gedbas4all

Mit dem Übertragen der Rohdaten vom DES in gedbas4all ist nur ein kleiner Zwischenschritt erreicht. Es muss für jede Quellengattung eine Datenmodellierung in gedbas4all gefunden werden. Anschließend müssen die Rohdaten in dieses Modell übertragen werden. Für die Adressbuchdaten gibt es hier schon die größten Vorarbeiten, aber z.B. im Bereich der Firmeneinträge ist noch viel zu tun. Auch für anderen Quellengattungen (Verlustlisten, Kirchenbücher, Standesamtsregister) müssen noch Datenmodelle und Umformungsregeln entwickelt werden.

GOV Synchronisation

Ebenfalls als Bestandteil von gedbas4all-wikibase-import gibt es ein Programm, das die letzten Änderungen im GOV verfolgt und automatisch neue Einträge oder Änderungen in Wikibase vornimmt.

Migration der Bibliographie der Adressbücher

Es ist sinnvoll, dass nicht nur die Daten der Adressbüchern, sondern auch die Bibliographie der Adressbücher in gedbas4all gepflegt wird. Dann lassen sich die Einträge direkt mit den Büchern verbinden und Auswertungen durchführen. Ein Programm exportiert die im GenWiki vorhandenen Daten und erzeugt daraus eine Tabelle. Nachdem diese Tabelle bereinigt wurde, soll ein weiteres Programm (das es noch nicht gibt) daraus Einträge in gedbas4all anlegen.

Mitmachen

Wer Lust bekommen hat, sich an der Entwicklung zu beteiligen, ist herzlich willkommen. Wie man vielleicht schon gemerkt, werden sind Java-Entwickler*innen am dringendsten gesucht. Aber gerade im Bereich von Wikibase ist auch Expertise in Systemadministration gefragt. Auch wenn die Weiterentwicklung der Weboberfläche gerade nicht höchste Priorität hat, lässt sich auch da was machen – der Clou bei Thymeleaf ist nämlich, dass es sich um (fast) normale HTML-Seiten handelt.

Die Entwicklung von gedbas4all wird hier in Discourse besprochen. Ansonsten freue ich mich über eine E-Mail an jzedlitz@compgen.de.