Beiträge zu Innovationen in unserem IT-Bereich

TYPO3 CMS zähmt Java EE Microservices

Nach langer Zeit ist es mir nun wieder gelungen, einen Beitrag zum Thema Microservices zu schreiben. In diesem Artikel möchte ich über unsere Erfahrungen im Bereich Frontend-Integration berichten. Das Ergebnis des entsprechenden Projektes „Modernisierung der Einbanddatenbank“ kann hier angeschaut werden. Aufgrund der fachlichen Anforderungen

  • ein Redaktionssystem zum Erstellen von statischen HTML-Seiten anzubieten und
  • die Pflege von HTML-Seiten in mehreren Sprachen zu unterstützen.

wurde ein Content Management System (CMS) zur Umsetzung ausgewählt. Weitere zentrale fachliche Anforderungen, welche in Use-Cases ausformuliert vorlagen, waren:

  • die Umsetzung komplexer Suchanfragen über unterschiedliche fachliche Entitäten sowie
  • die Erfassung von Metadaten zu Entitäten zur Erforschung von Einbänden des 15. und 16. Jahrhunderts.

Nachdem wir die fachlichen Anforderungen mit Hilfe des Konzeptes Domain Driven Design (DDD) aufgeteilt hatten, haben wir uns entschieden, jeden fachlichen Bereich (Bounded Context) als Microservice zu implementieren. Bedingt durch die Tatsache, dass nur ein Entwicklungsteam alle Anforderungen umsetzen sollte, wurden die fachlichen Anforderungen nicht zu kleinteilig auf folgende Microsevices aufgeteilt:

  • die Einbandsuche, zur Umsetzung aller Suchanfragen und Darstellung der Trefferlisten und
  • den Einbandnachweis, zur Umsetzung aller Anforderungen der Erfassung von fachlichen Entitäten.

In diesem Projekt haben wir uns dazu entschieden dem Ansatz des Self-contained-Systems zu folgen. Self-contained-Systems legen verschiedene Makro-Architekturentscheidungen fest. Unter anderem ist definiert, dass jeder Microservice eine autonome Webanwendung ist. Das bedeutet, dass jeder Microservice sein eigenes User-Interface ausliefert. Die wesentliche Herausforderung beim Einsatz dieser Architektur stellt die Bereitstellung eines optisch einheitlichen und konsistenten User-Interfaces über alle Systeme hinweg und die Integration von Cross-Cutting Concerns, wie zum Beispiel der Authentifizierung, dar. Die nachfolgende Abbildung illustriert die Architektur des Projektes:

Abbildung 1: Architektur Einbanddatenbank

Die Gesamtdarstellung der Webseite inklusive aller Navigationselemente wird durch das CMS TYPO3 erzeugt. Um nun die einzelnen Darstellungen der Suche und Erfassung integrieren zu können, haben wir drei Erweiterungen geschrieben. TYPO3 bietet dazu einen Plugin-Mechanismus, welcher es ermöglicht, das CMS um zusätzliche Funktionalitäten zu erweitern.

 

Lookup Extension

Die Erweiterung mit dem Namen „Lookup“ wird benötigt, damit das TYPO3 CMS dynamisch ermitteln kann, wo sich der entsprechende Microservice im Netzwerk befindet. Dazu wird mit Hilfe des Namens des Microservice die Serviceregistry angefragt. Diese liefert wiederum die Angaben der aktuellen IP-Adresse und des TCP/IP-Ports des Microservices aus. Somit kann TYPO3 jederzeit dynamisch zur Laufzeit und ohne Konfigurationsaufwand auf Veränderungen im Bereich der Microservices reagieren. Unter Betrachtung des Aspektes der Skalierung eines Microservices ist TYPO3 mit Hilfe dieser Erweiterung in der Lage, auch mehrfach installierte Microservices parallel anzusprechen und auf zunehmende Nutzeranfragen einer Seite zu reagieren.

 

Frontendintegration Extension

Die Frontendintegration Extension ermöglicht es, auf jeder beliebigen HTML-Seite innerhalb des CMS Inhalte eines Microservices zu integrieren. Dazu verwendet die Frontendintegration Extension die Lookup Extension um den entsprechenden Microservice über Konfigurationswerte zu ermitteln. Anschließend werden die adressierten HTML-Elemente mittels eines HTTP-Clients abgerufen und auf der entsprechenden Seite dargestellt. Ein HTML-Element wird mit Hilfe des Attributes „ID“ identifiziert. Die Konfiguration im Backend von TYPO3 sieht wie folgt aus:

Abbildung 2: Konfiguration Frontend Extension

Diese Konfiguration bindet den Microservice mit dem Namen „einbandsuche“ via Serviceregistry und unter Verwendung des Servicegateways ein. Der Servicegateway stellt einen sogenannten „Edge“ Service dar, mit Hilfe dessen zusätzliche Aspekte wie das angleichen von URL Adressen, Anpassung von HTTP Headern oder Routing zwischen den Services transparent umgesetzt werden kann. Innerhalb des Microservices wird die Seite werkzeugsuche.html mit dem Query Attribut language=en eingebunden. Auf dieser Seite muss ein HTML-Element mit der ID „content“ existieren, welches durch die Extension extrahiert wird. So können gezielt einzelne HTML-Komponenten kombiniert werden, damit nicht die gesamte durch den Microservice erzeugte HTML-Seite übernommen werden muss. Dadurch besteht innerhalb des TYPO3 die Möglichkeit, statische Inhaltselemente mit Inhalten eines Microservices zu kombinieren und gemeinsam auf einer Seite darzustellen.

 

OAUTH2 Extension

Aufgrund der fachlichen Anforderung, dass sich bestimmte Nutzergruppen am System anmelden sollen, um damit Zugriff auf die Funktionalität der Erfassung zu bekommen, musste eine Authentifizierungslösung integriert werden. Zur Umsetzung dieser Anforderung konnten wir unseren bereits in anderen Projekten erfolgreich genutzten OAUTH2 Indentity-Management-Microservice nachnutzen. Die Authentifizierung erfolgt hierbei nach dem standardisierten OAUTH2-Verfahren. Die TYPO3 Extension stößt dieses Verfahren an, sobald der Nutzer den Link zur Anmeldung aktiviert. Nach erfolgreicher Authentifizierung des Nutzers übermittelt TYPO3 mit Hilfe dieser Extension den JSON WEB Token (JWT) des Nutzers an den Microservice. So können die Identität und die Berechtigungen im Microservice ausgewertet und entsprechend fachlich darauf reagiert werden.

 

Mit Hilfe dieser drei Erweiterungen besteht für uns die Möglichkeit, jegliche komplexe fachliche Anforderungen außerhalb des TYPO3 umsetzen zu können. Dies bietet nicht nur den Vorteil, dass die einzelnen Microservices skaliert werden können, sondern gibt uns auch die Freiheit andere Technologien als PHP zur Erweiterung des CMS einzusetzen. In diesem Projekt konnte somit eine nahtlose Integration von Java-EE- und TYPO3-PHP-basierten Technologien umgesetzt werden. Ein weiterer Vorteil liegt darin, dass, wie bei allen Microservice-Architekturen, einzelne Komponenten unabhängig entwickelt und ausgerollt werden können. Aufgrund dieser Vorteile kann eine erhöhte Entwicklungsgeschwindigkeit erzielt und damit die fachlichen Anforderungen in weniger Zeit umgesetzt werden. Zusätzlich ist das Gesamtsystem in einigen Teilen widerstandsfähiger gegen Ausfälle. Fällt zum Beispiel die Komponente der Suche oder Erfassung aus, stehen die anderen statischen Seiten weiterhin zur Verfügung. Um diese Architektur umsetzen zu können, mussten allerdings auch einige technische Herausforderungen durch unser Team gemeistert werden.

 

Integration des Sprachwechsels.

Wechselt der Nutzer im CMS die Sprache, so wird durch TYPO3 der Pfad der Seite um das entsprechende Sprachkürzel erweitert. Ein Sprachwechsel im Browser und damit im http- Accept-Language Header wird nicht ausgewertet. Java EE hingegen wertet in mehrsprachigen Projekten standardmäßig den HTTP-Header aus. Um einen einheitlichen Sprachwechsel zwischen den Systemen zu gewährleisten, musste der entsprechende HTTP-Header-Wert künstlich eingefügt werden. Diese Aufgabe übernimmt der zwischengeschaltete Servicegateway. Die Servicegateway-Implementierung wurde mit Hilfe von Spring Boot und Spring Cloud umgesetzt. Das Spring-Framework selbst nutzt an dieser Stelle die Netflix-Bibliothek Zuul. Im Servicegateway-Projekt besteht die Möglichkeit, jegliche Kommunikation mit Hilfe von Filtern zu manipulieren. Ruft TYPO3 nun eine Seite mit dem Query Parameter language=en auf, setzt der Servicegateway automatisch den Accept-Header mit dem entsprechenden Wert in die Kommunikation mit dem Microservice ein. Dieser kann nun konform mit der Umschaltung im TYPO3 die Seite in der gewünschten Sprache ausliefern.

 

AJAX POST Requests

Für die Umsetzung der HTML-Seite für einen Java-EE-Microservice haben wir die User-Interface-Bibliothek Primefaces verwendet. Diese bietet den Vorteil der einfachen und schnellen Umsetzung von komplexen HTML-Komponenten. Diese sind in allen Browsern darstellbar und werden ständig durch Primefaces gepflegt und erweitert. Zur Umsetzung dynamischer Komponenten verwendet Primefaces sehr häufig die asynchronen Javascript (AJAX) POST-Requests. Allerdings werden diese nicht durch die Erweiterung MS-Frontend TYPO3 registriert und müssen mit Hilfe einer expliziten Apache-Redirect-Regel an den Servicegateway weitergeleitet werden. Auch das Einbinden der CSS und Javascript-Datei, welche durch Primefaces verwendet werden, muss explizit im TYPO3 mit angegeben werden. An diesem Punkt müssen wir die Frontend-Extension noch weiterentwickeln, sodass die bisherige Lösung via Redirect abgelöst werden kann.

 

Anpassungen automatisch generierter Links.

Innerhalb der Microservices werden durch die Frontend-Bibliotheken Java-Server-Faces und Primefaces Links automatisch auf Basis der verwendeten XHTML-Template-Namen generiert. Sind diese nicht konform mit den Links innerhalb des TYPO3 CMS, müssen sie angepasst werden. Diese Anpassungen werden durch einen weiteren Filter des Servicegateways durchgeführt. Allerdings ist es empfehlenswert, die Links der Microservices so zu gestalten, dass diese nicht mehr angepasst werden müssen.

 

Zusammenfassung

Die Integration der Self-contained-System-Microservices in das TYPO3 CMS als Portal-Lösung ist eine große Herausforderung. Das Ergebnis ist allerdings beeindruckend, wenn man sich vorstellt, dass einige Seiten zu großen Teilen auf einem anderen Server als dem CMS-Server generiert werden. Auch die organisatorischen Vorteile im Rahmen der Entwicklung und der Continuous Integration / Deployment sind spürbar. Im Falle eines Integrationsfehlers ist allerdings aufgrund der Komplexität der Integration die Fehlersuche aufwendig. Hilfreich wäre hier der Einsatz eines Tracing Tools wie es im Spring Cloud-Framework bereits zur Verfügung steht. Abschließend bleibt zu sagen, dass diese Architektur große Möglichkeiten und Flexibilität bietet, aber auch wirklich nur angewendet werden sollte, wenn die funktionalen und nichtfunktionalen Anforderungen an das zu entwickelnde System einen Einsatz rechtfertigen. Für den Aufbau eines solchen Systems sind Kompetenzen aus vielen Bereichen der Softwareentwicklung im gesamten Team notwendig. Denn nur wenn jedes Teammitglied verstanden hat wie das gesamte System arbeitet, ist diese Architektur eine Basis für einen erfolgreichen Betrieb, und ermöglicht zusätzlich eine leichte Erweiterbarkeit und Weiterentwicklung.

Glück und Glas – wie leicht bricht das! Der Relaunch der Einbanddatenbank (EBDB)

 

Ein Beitrag von Andreas Wittenberg

Wer kennt nicht dieses Sprichwort und wer hat es – aus ganz unterschiedlichen Gründen – nicht schon einmal verwendet? Dass der Mensch zuweilen ein wenig auf glückliche Umstände angewiesen ist, um sein Leben zu meistern, wusste man schon zu allen Zeiten. So verwundert es also nicht, dass bereits im 16. Jahrhundert diese Lebensweisheit auch die Graveure und Buchbinder inspirierte, und unser Sprichwort auf den Einbänden von Büchern aus dieser Zeit zu finden ist.

Fortuna, das Glücksrad in der Hand haltend. Prägeplatte auf einem Druck von 1567
Unter der Darstellung beschreibt ein zweizeiliger Text die dargestellte Figur: FORTVNA VITREA EST CVM // MAXIME SPLENDET FRANG[itur] (Das Glück ist wie Glas: Wenn es am meisten glänzt, zerbricht es)

Das Glücksrad mit den Initialen H und C für den Wittenberger Buchbinder Hans Cantzler

Dieses Motiv ist nur eines von sehr vielen, die auf Bucheinbände der Frühen Neuzeit mit Hilfe verschiedener Werkzeuge geprägt wurden. Richtig interpretiert bieten die so verzierten Bucheinbände wichtige Informationen zur Genese von Handschriften und Drucken. Aber auch zur Kunstgeschichte, zur Handwerks- und Sozialgeschichte sowie zu den historischen und theologischen Ereignissen jener Zeit können sie wichtige Aussagen treffen.

Um diese Erkenntnisse in kompakter und gut zugänglicher Form der Fachcommunity zur Verfügung zu stellen, gibt es seit 2001 die Einbanddatenbank (EBDB). Diese unter Federführung der SBB entwickelte Spezialdatenbank war seit ihrer Freischaltung im Netz ein Kooperationsprojekt zwischen mehreren Bibliotheken. Unsere eingangs erwähnte Fortuna war dem Projekt sehr freundlich gesonnen, denn  die Bestände in den drei bereits seit Projektbeginn beteiligten Bibliotheken Berlin, Stuttgart und Wolfenbüttel ergänzen sich in überaus glücklicher Weise und bildeten die Basis für den weiteren Ausbau der Datenbank.

Inzwischen sind weitere Partner dazugekommen, nicht nur aus Deutschland. Die EBDB entwickelt sich zum zentralen Nachweisinstrument für deutsche Bucheinbände aus dem 15. und 16. Jahrhundert. Um den technischen Innovationen, aber auch dem sich veränderten Rechercheverhalten der User Rechnung zu tragen, wird zurzeit in der SBB in enger Kooperation der Abteilungen Historische Drucke und Information- und Datenmanagement ein Relaunch der Datenbank durchgeführt.

Am Projekt beteiligte KollegInnen vor historischen Drucken aus der Einbandsammlung der SBB

Die sehr detaillierten und umfangreichen Informationen zu Buchbindern, Werkzeugen, Provenienzen sowie Motiven können künftig wesentlich besser recherchiert werden. Die sich in den vergangenen Jahren als richtig und sehr zielführend erwiesene Strategie, neben den beschreibenden Metadaten auch konsequent  Images der Werkzeuge zur Verfügung zu stellen, wird beibehalten und weiter ausgebaut. Ein absolutes Novum in der Einbandforschung waren die mit der Etablierung der EBDB eingeführten normierten Bezeichnungen für die auf den Einbänden verwendeten Motive.

Im April 2018 wurden die bisher beim Relaunch erreichten Ergebnisse den Projektpartnern vorgestellt. Während des Treffens in der SBB konnten die teilnehmenden EinbandspezialistInnen Wünsche und Erwartungen, Anregungen und Kritik direkt mit den KollegInnen der IT-Abteilung beraten.

Techniker unter sich: KollegInnen der Abteilung IDM während des Treffens in der SBB

Fortuna begleitete auch dieses Treffen wohlwollend, denn es kam – wie erhofft – zu sehr fruchtbaren Gesprächen zwischen den Fachleuten aus sehr disparaten Disziplinen.

Projektpartnertreffen am 23. April 2018 in der SBB

Die Ergebnisse des Treffens werden in die weitere Entwicklung der Einbanddatenbank einfließen, dadurch diese Anwendung zukünftig weiter verbessern und so der Erforschung des Bucheinbands neue Impulse geben. Bei dieser Arbeit sind weitere Projektpartner der EBDB sehr willkommen. Bei diesen – und auch bei allen anderen Nutzern und Kollegen – soll ein Blick auf die Eingangsseite der „neuen“ Datenbank schon jetzt das Interesse und die Neugierde wecken.

Gehen wir davon aus, dass Fortuna auch weiterhin allen an der EBDB Beteiligten so wie bisher gewogen bleibt – dann steht sicher dem Umstand nichts im Wege, dass Entwickler, Projektpartner und Nutzer (hier seien ausdrückliche alle weiblichen Formen einbezogen!) durch ihre segensreiche Tätigkeit auf einer Leiter direkt in den Himmel gelangen –  vielleicht so, wie es einst im Alten Testament (Gen 28,11) in der Erzählung vom Traum Jacobs beschrieben wurde…

 

So wird sich die EBDB künftig im Netz präsentieren

Der Traum Jacobs von der Himmelsleiter. Geprägt auf einem Bucheinband von     1588

Die Initialen H und B weisen auf den Wittenberger Buchbinder Hans Blume

Stimmen der Bibliothek: Digitalisierung der Bibliotheken

Bibliotheken sind seit Jahrhunderten etablierte Spieler im Bereich der Wissenssammlung und -katalogisierung und sehen sich im digitalen Zeitalter einer Reihe von Herausforderungen gegenüber.

Im Podcast “Forschergeist” des Stifterverband für die Deutsche Wissenschaft e.V. spricht Tim Pritlove mit Ralf Stockmann, Leiter des Referates „Innovations-Management – Online-Bibliotheksdienstleistungen“ an der Staatsbibliothek zu Berlin über traditionelle und zukünftige Rollen von Bibliotheken.

Thematisch wird ein weiter Bogen gespannt: der Zugang zu Wissen und Forschung, die Erschließung und Katalogisierung von Quellen, das Aufbereiten und Verfügbarmachen der Daten, die Bewahrung und Archivierung der gewonnenen Informationen, das Verhältnis der Bibliotheken zu Wissensprojekten wie Wikipedia und Suchmaschinen.

Auch denkbare Zukunftsfelder für eine digitale Transformation von Bibliotheken werden gestreift: die Möglichkeiten der Analyse von Big Data (Kataloge als Objekt von Forschung) oder die Anwendung neuer Methoden des maschinellen Lernens und der künstlicher Intelligenz.