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.