CC0 Staatsbibliothek zu Berlin – Stiftung Preußischer Kulturbesitz | Elemente von Canva/@sketchify | Kollage von Carolin HahnVon Microservices bis Macroinstructions –Die Gesamtarchitektur des Handschriftenportals
Ein Interniew zwischen Konrad Eichstädt und Carolin Hahn (beide SBB).
Jedes solide Gebäude benötigt ein Fundament, tragende Wände, Zwischendecken, Lifte, Fenster, Türen – und natürlich ein Dach. Ähnlich ‘modulreich’ ist auch ein Software-Gebäude: Ob Server oder verschiedene über eine Queue kommunizierende Systemmodule, ob Frontend-Entwicklung, Metadatenmanagement oder facettierbare Suche – all das muss konzipiert, programmiert, aufeinander abgestimmt und getestet werden, bevor die ersten Nutzer:innen den Rohbau – die Alpha-Version – betreten können.
Konrad Eichstädt trägt solcherart Entscheidungen mit und projektiert die Gesamtarchitektur des Handschriftenportals. Neben Fragen nach zu verwendenden und möglichst gut zu wartenden Systemmodulen formuliert er als Softwarearchitekt auch Ansprüche an die Datensicherheit und Barrierearmut. Das Ziel: Ein Gebäude zu errichten, das möglichst stabil ist, lange genutzt werden kann und für alle Anspruchsgruppen gut zugänglich ist.
Steckbrief
Name:
Konrad Eichstädt (SBB)
Rolle im Projekt:
Softwarearchitekt
Institutionelle Anbindung:
Abteilung Informations- und Datenmanagement der SBB
Mitarbeiter im Sachgebiet „Management fachspezifischer Nachweissysteme und Datenbanken“
1. Ein Gedankenspiel: Wir betreten die Portal-Baustelle. Hier ein Lastenkran, dort ein frisch verlegtes Starkstromkabel. Wie sieht der Rohbau des Handschriftenportals derzeit aus? Ist das Souterrain fertiggestellt oder bereits ein paar höhere Stockwerke?
Aufgrund der Tatsache, dass das Fundament der wichtigste Bestandteil eines Gebäudes ist, haben wir uns dafür viel Zeit gelassen. Meiner Meinung nach haben wir bereits diese Basis und das Erdgeschoss aufgebaut. Wir sind in der Lage, Bestandsdaten in Form von XML-Dateien aufzunehmen und diese bis in die Präsentationsschicht des Systems durchzureichen. Dazu wurden die wichtigsten Module erstellt und mit entsprechenden Kommunikationsschnittstellen (APIs) versehen. Die asynchrone Kommunikation zwischen den Modulen erfolgt dabei auf der Basis der Open-Source-Software Apache Kafka. Diese Integration bietet große Flexibilität für die Erweiterbarkeit und Stabilität des Gesamtsystems.
2. Wie würden Sie Ihre Rolle im Projektzusammenhang beschreiben? Wofür genau sind Sie als Softwarearchitekt verantwortlich?
Wie beim Hausbau ist der Architekt für die Planung und Prüfung der Umsetzung zuständig. Allerdings wird die Planung im Vergleich zu einer Gebäudearchitektur sehr viel agiler den entsprechenden Anforderungen und Gegebenheiten angepasst. Als Softwarearchitekt bin ich dafür verantwortlich, gemeinsam mit dem Entwicklungsteam die beste technische Lösung zur Erfüllung der funktionalen Anforderungen umzusetzen. Die Nutzer:innen unseres Systems sollen eine moderne und intuitive Erfassung einer Handschriftenbeschreibung durchführen können. Sämtliche Metadaten der Kulturobjekte und entsprechenden Handschriftenbeschreibungen sollen durchsuchbar gemacht und im Web dargestellt werden. Daher besteht die Aufgabe des Softwarearchitekten zu großen Teilen aus der ‘Kommunikation an der fachlich-technischen Schnittstelle’, um die Anforderungen zu evaluieren und die Architektur zu planen. Als Ergebnis dieser Arbeiten können im Anschluss neue Funktionen durch das Entwicklungsteam effizient umgesetzt werden.
3. Das Handschriftenportal ist nicht ‚eine’ einzige Software, sondern besteht aus zahlreichen autarken Bausteinen, die miteinander kommunizieren. Diese sogenannten ‚Microservices’ sind Systemmodule, die vollkommen unabhängig voneinander funktionieren. Welche Vorteile hat diese Art der Systemarchitektur?
Dieser Architekturstil bietet viele Vorteile, aber stellt die Entwicklungsteams auch vor einige Herausforderungen. Ein entscheidender Vorteil ist meiner Meinung nach, dass eine fachliche Aufgabe innerhalb eines Microservices umgesetzt wird. Um alle fachlichen Anforderungen in einzelne zusammengehörige Aufgabenbereiche zu zerlegen, sind wir nach dem Ansatz des Domain-Driven Designs vorgegangen. Die durch Eric Evans im Jahr 2004 vorgestellte Vorgehensweise ermöglicht es, die gesamten Anforderungen in zusammengehörige Aufgabengruppen zu zerlegen. Jede dieser Aufgabengruppen ist dann innerhalb eines Microservices bearbeitbar. Die Größe einer Aufgabengruppe sollte so gewählt werden, dass diese gut durch ein Entwicklungsteam umgesetzt werden kann.
Der Vorteil dieser Herangehensweise ist, dass so eine zusammengehörige Anforderungsgruppe mithilfe der bestmöglichen technischen Lösung umgesetzt wird, ohne direkte Wechselwirkungen mit anderen Aufgabengruppen herzustellen. An den Grenzen zu anderen Aufgabengruppen müssen die Abhängigkeitsbeziehungen und Schnittstellen definiert werden. Diese fachliche Zerlegung aller Anforderungen und Schnittstellendefinitionen bildet die Grundlage für das technische System, welches in vielen Punkten sehr flexibel angepasst werden kann. Ein einzelner Microservice kann so zum Beispiel mehrfach installiert werden, um eine höhere Anzahl an HTTP-Requests an diesen Service – gemeint sind einzelne Nutzer:innen-Aktionen auf einer Website – beantworten zu können. Änderungen, welche sehr oft durch neue oder veränderte fachliche Anforderungen verursacht werden, betreffen in der Regel nur einen Microservice und nicht das gesamte System. Dadurch lassen sich in kürzerer Zeit (s. Time-to-Market) neue Anforderungen umsetzen und diese auf produktive Systeme überführen.
Module der HSP-Gesamtarchitektur
Wie lässt sich ein solch komplexes System testen und warten? Ein einzelner Microservice lässt sich leichter testen, da die Anzahl der Quellcodezeilen geringer und die umzusetzenden Aufgaben nicht so umfangreich sind. Allerdings muss auch die Summe aller Teile – das Gesamtsystem – geprüft werden, denn das Zusammenspiel aller Microservices ist in der Architektur komplexer als in einer monolithischen Softwarelösung, in der alle Anforderungen in einem einzigen Modul implementiert sind. Sämtliche Microservices kommunizieren über das Netzwerk miteinander. Grundsätzlich unterscheidet man hier zwei Arten der Kommunikation: Bei der ‘synchronen Kommunikation’ wartet der aufrufende Microservice auf die Antwort des aufgerufenen Microservices. Bei der ‘asynchronen Kommunikation’ stellt der aufrufende Microservice eine Nachricht innerhalb einer Vermittlungssoftware zur Verfügung und wartet nicht auf die direkte Antwort des Zielsystems. Je nach gewählter Kommunikationsform ist das Verhalten des Gesamtsystems ein anderes – und damit auch anders zu testen. Die Funktionalität des Gesamtsystems zu überprüfen, bedeutet einen hohen Aufwand, da sowohl alle Microservices als auch die Kommunikationssoftware zur Verfügung stehen müssen. Das Verhalten eines solchen verteilten Systems ist komplex und benötigt sehr viel Erfahrung im Umgang mit Fehlern. Daher sind das Testen und der Aufbau dieses verteilten Systems eines der größten Herausforderungen der Microservice-Architektur. Sind die entwickelten Softwarekomponenten auch für andere Vorhaben nachnutzbar? Ja, denn selbst für das Handschriftenportal nutzen wir bereits Microservices aus vorherigen Projekten nach. Wir werden die Authentifizierung und Autorisierung über einen ‘Identity Management Microservice’ auf Basis von OAUTH2 und JSON Web Token durchführen. Diesen Microservice haben wir bereits im Rahmen eines unserer ersten Projekte umgesetzt. Im Handschriftenportal werden wir einen Service entwickeln, welcher die sogenannten Normdaten zu Personen, Orten, Körperschaften und weiteren Metadaten verwaltet. Der Service ist so konzipiert, dass er auch durch andere Systeme innerhalb der Staatsbibliothek zu Berlin nachgenutzt werden kann.
4. Inwiefern werden Sie mit Linked Open Data arbeiten und gibt es hierzu ggf. schon Best Practices, auf die Sie bei der Entwicklung zurückgreifen können?
Die aktuelle Planung sieht vor, dass die Verwaltung und Präsentation der Normdaten auf Basis von Linked Open Data durchgeführt wird. Dabei stimmen wir uns eng mit der Metadatenstelle der Staatsbibliothek zu Berlin ab. Wir haben damit begonnen, die Modelle für Orte und Körperschaften auf Basis der GND-Ontologie zu modellieren. Darüber hinaus werden alle Normdatenentitäten durch Beziehungen auf Basis von RDF miteinander verknüpft. Diese Vorgehensweise bietet uns die Möglichkeit, die eigenen Modelle flexibel zu erweitern und diese leicht mit den Daten der GND abzugleichen. Darüber hinaus erlaubt es die Modellierung von Normdaten als Beziehungsgraph, neue Erkenntnisse auf Basis von Graphenabfragen zu gewinnen.
Graphen-Visualisierung
5. Was waren die bisher größten Herausforderungen?
Die größten Herausforderungen liegen auf zwei unterschiedlichen Bereichen der Architektur: Erstens geht es darum, die unterschiedlichen fachlichen Anforderungen der Stakeholder zu bündeln und in den technischen Bereich zu kommunizieren. Dabei müssen häufig sowohl fachliche als auch technische Kompromisse gefunden werden. Das Handschriftenportal geht in beiden Bereichen neue Wege. Das ‘Kulturobjektdokument’ beispielsweise ist eine neue fachliche Entität, deren ‘Verhalten’ und Metadaten erst fachlich definiert und abgestimmt werden mussten. Daten der Altsysteme kennen diese fachliche Entität nicht, sodass diese digitale Repräsentanz eines Kulturobjekts erst entsprechend erzeugt werden musste.
Die zweite große Herausforderung liegt im Bereich der technischen Zusammenführung einer Gesamtpräsentation aller Module. Denn selbst in der bereits etablierten Microservices-Architektur ist der Aufbau einer konsistenten Gesamtdarstellung noch Neuland. Ein Microservice kann ein eigenes Microfrontend – eine eigene kleinere Webpräsentation – generieren. So können Nutzer:innen beispielsweise in einem System nach Metadaten suchen, in einem anderen jedoch ihren persönlichen virtuellen Arbeitsplatz anlegen. Der bzw. die Nutzer:in bemerkt jedoch im Idealfall nicht, dass es sich um zwei unterschiedliche Technologien handelt – beide Module fließen in einem Browserfenster zusammen. Neben der Microfrontend-Integration gibt es noch weitere Verfahren, Benutzeroberflächen unterschiedlicher Module zusammenzuführen. In unserem Projekt ist dieser Aspekt der Architektur nur zum Teil geklärt. Das Handschriftenportal wird aus zwei großen Einzeldarstellungen, der Präsentation und der Erfassung, bestehen. Beide Module stellen jeweils die dazugehörigen Funktionen der einzelnen Services zur Verfügung. Die einheitliche Gesamtdarstellung im Browser von Präsentation und Erfassung ist noch ein offener Punkt der derzeitigen Architektur.
6. Ein Blick in die nahe Zukunft: Stehen morgen konkrete Aufgaben im Projektkontext an? Welche sind das?
Zum einen beginnen wir mit der Erarbeitung einer Lösung für das Erfassungsmodul von Handschriftenbeschreibungen im TEI-XML-Format. Zusätzlich werden wir für die drei Erfassungsmodule – Nachweis, Import und Normdaten – eine aktive Datenbank erstellen. Bis zum heutigen Tag waren die Daten dieser Service lediglich im Arbeitsspeicher des jeweiligen Servers verfügbar.
7. Welche Ziele haben Sie sich für die nächsten sechs Monate gesetzt?
Für den Bereich der Erfassung soll es die Möglichkeiten geben, die im TEI-XML codierten Daten einer Beschreibung zu erfassen und zu bearbeiten. Im Bereich der Präsentation ist eine komplexe Suche in den Daten aller Kulturobjektdokumente und Beschreibung fertiggestellt. Die Suchergebnisse können in einer IIIF–konformen Darstellung angezeigt werden.
8. In einem Satz: Welches Problem wird das Handschriftenportal lösen?
Es schafft die Möglichkeit einer zentralen, einheitlichen und modernen Erfassung und Präsentation für mittelalterliche und frühneuzeitliche Handschriften. Die erfassten Daten können mit normierten Metadaten verknüpft und angereichert werden.
Ihr Kommentar
An Diskussion beteiligen?Hinterlassen Sie uns einen Kommentar!