Beiträge

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.

Microservices, Sicherheit

Dieser Beitrag in unserer Blogserie zum Thema Microservices, behandelt das Thema Authentifizierung und Autorisierung basierend auf dem OAUTH2 – Verfahren. Es werden die Vorteile und Herausforderungen dieser Lösung erörtert.

Im Rahmen der Entwicklungsprojekte der Staatsbibliothek zu Berlin, ist eine technische Anforderung, die nahezu in jedem Projekt gefordert wird, die Anmeldung von Benutzern und die Verwaltung der entsprechenden Benutzerrechte und Rollen. Es ist dabei zu prüfen, ob diese Anforderung im Rahmen einer Organisationslösung oder als eine individuelle, projektspezifische Lösung umgesetzt wird. Eine mögliche Organisationslösung sollter meiner Meinung nach folgende wichtige Anforderung unterstützen:

  • Integrierbarkeit in eine Microservices Architektur.
  • Unterstützung mehrerer Authentifizierungsverfahren, wie zum Beispiel, LDAP, Shibboleth oder ein individuelles Verfahren.
  • Unterstützung von Single Sign On und Single Sign Out.
  • Unterstützung verschiedenster Anwendungen.
  • Individuelle Erweiterbarkeit.

Im Vorfeld zur Lösungsbeschreibung möchte ich einige Begriffe, welche häufig in diesem Kontext verwendet werden, erläutern.

Authentifizierung
Die Authentifizierung dient der Überprüfung der Benutzeridentität. In der Regel geschieht dies mit der Eingabe eines Benutzernamens und eines Passworts.

Autorisierung
Hierunter werden die Gewährung von Benutzerrechten und das Zulassen bzw. Verweigern der entsprechenden Aktion in der Anwendung verstanden.

Single Sign On / Single Sign Out
Mittels Single Sign On wird das einmalige Anmelden am System ermöglicht, um mehrere Anwendungen ohne wiederholte Anmeldung nutzen zu können. Analog existiert der Single-Sign-Out-Mechanismus zum Abmelden.

LDAP
Ein Verzeichnis Dienst zur Verwaltung von Benutzerinformationen.

Token
Ein codierter Text welcher Nutzer bzw. Zugriffsinformationen enthält. Enthält allerdings keine Passwortinformationen.

Begibt man sich in diesem Bereich auf die Suche nach möglichen aktuellen Verfahren und Lösungen, findet man folgende populäre Lösungsansätze, welche einige der oben genannten Anforderungen unterstützen:

OAUTH2
OAUTH2 ist eine reine Autorisierungslösung und der Nachfolger von OAUTH 1.0. Das OAUTH2 Protokoll ermöglicht Anwendungen, Zugriff auf Webservices mit begrenzten Benutzerinformationen zu erhalten. Es wird bereits durch Anbieter von Webservices, wie zum Beispiel Facebook, Google oder auch Twitter verwendet. Alle Informationen zum Verfahren können Sie unter folgendem Link nachlesen.

OPEN ID Connect
Open ID Connect ist eine einfache Identitätsverwaltungsschicht basierend auf OAUTH2. Es ermöglicht Client Anwendungen die Identität eines Nutzers zu verifizieren und Nutzerinformationen zu erhalten. Es basiert auf HTTP REST Kommunikation.

SAML2, Security Assertion Markup Language
SAML2 ist ein Standard zum Austausch von Authentifizierungs-, und Autorisierungsinformationen und Nachfolger vom SAML Standard. SAML 2.0 ist XML-basiert und benutzt Sicherheitstoken zum Austausch von Nutzerinformationen. SAML basiert auf dem Zusammenspiel von einem Principal, dem Benutzer, einem Serviceprovider, einem Webservice zum Zugriff auf eine geschützte Ressource und einem Identity-Provider zur Prüfung der Identität eines Benutzers. SAML2 ist damit eine sogenannte Enterprise – Lösung, welche im gesamten Unternehmen bzw. der Organisation eingesetzt werden muss.

Für alle diese Verfahren sind bereits vielfältige Softwarebibliotheken und Produkte entwickelt worden. Eine Auswahl an Produkten welche diese Verfahren unterstützen sind folgende:

Eine gute Wahl ist meiner Meinung nach das Spring Security Framework. Die wichtigsten Gründe dafür sind:

  • Die gute Integrationsmöglichkeit für die Nutzung REST basierten Microservices,
  • Die Möglichkeiten der individuellen Erweiterbarkeit,
  • Die Unterstützung aller gängigen Authentifizierungsverfahren und Standards
  • Eine aktive Community und Weiterentwicklung
  • Die gute Integration in die Spring-Technologie.

Wie genau kann nun aber eine Lösung aussehen?

Eine mögliche Lösung hierfür wäre eine Remote-Fassade im Bereich der Sicherheit aufzubauen. Diese kann mögliche Autorisierungsverfahren verstecken und in Richtung der Anwendungen auf ein Verfahren standardisiert werden. Alle Anwendungen sind auf Basis des OAUTH2 Verfahren integriert.Folgende Abbildung veranschaulicht die Komponenten und das Verfahren.

Authentifizierung, Remote Fassade

Authentifizierung, Remote Fassade

Möchte der Benutzer eine Anwendung verwenden, wird dieser bei fehlender Authentifizierungsinformation auf die Anmeldeseite (Login) des Identity-Managementservers weitergeleitet. Dort kann der Nutzer seine Benutzerkennung eingeben und wird nach erfolgreicher Anmeldung zur ursprünglichen Anwendung zurück geleitet. Dieses Verfahren basiert auf dem OAUTH2 Flow „Authorization Code Grant“. Es können hier allerdings auch andere Flows für eine Anwendung verwendet werden. Beim Umleiten der Nutzeranfrage vom Identity-Management zur Anwendung wird dieser Umleitung ein sogenannter Token mitgegeben. Hier sollte meiner Meinung nach ein JSON Web Token (JWT) verwendet werden. Dieser Token enthält alle nutzerspezifischen Informationen und die entsprechenden Rechte und Rollen für diesen Benutzer. Die Anwendungen können nun diesen JWT auswerten und die entsprechenden Aktionen innerhalb der Anwendung zulassen bzw. verweigern. Zusätzlich zu dem OAUTH2 Standardverfahren ist es jetzt aber möglich für jede Anwendung ein Auhentifizierungsverfahren festzulegen. So könnte festgelegt werden, dass Benutzer der Anwendung A sich gegen das LDAP authentifizieren und Benutzer der Anwendung B sich gegen einen SAML2 Identity Provider authentifizieren. Hier agiert das Identity Management als eine Remote-Fassade zur Kapselung möglicher Authentifizierungsverfahren. Mit Hilfe des JWT können alle benutzerspezifischen Informationen platziert und ohne einen erneuten Login durch die Anwendungen ausgewertet werden.

Welche Vorteile bietet eine solche Lösung?

Diese Lösung hat den Vorteil, dass beliebige Authentifizierungsverfahren einmalig integrieren und mehrfach nachgenutzt werden können. Zusätzlich wird in Richtung der Anwendungen auf ein Verfahren standardisiert, was für die Client-Anwendungen weniger Anpassungen bei Erweiterungen des Indentity-Managements bedeutet und letztendlich auch Betriebsaufwände verringern kann. Ein weiterer Vorteil ist, dass jegliche Anwendungen mit allen benötigten Benutzerinformationen versorgen können ohne jemals die Benutzerauthentifizierung im Netzwerk ausgetauscht zu haben. Mit Hilfe des JWT können so auch Microservices ohne Userinterface die Nutzerinformationen erhalten und auswerten.

Welche Herausforderungen bringt diese Lösung mit sich?

Eine Herausforderung ist natürlich die Integration komplexer Authentifizierungsverfahren wie zum Beispiel SAML2. Hierbei müssen die Anmeldeinformationen bei dem entsprechenden Identity Provider der jeweiligen Organisation eingegeben werden und nicht im Standard-Login des Identity-Managements.
Eine weitere Herausforderung ist die unterschiedliche Darstellung derselben Anmeldeseite für unterschiedliche Anwendungen. Mögliche Ansätze zur Lösung dieser Thematik könnten auf Frontend-Komposition basieren. Dies bedeutet, dass die Anmeldeseite in die jeweilige Anwendung integriert und somit dem Anwendungslayout angepasst wird.
Neben der Anmeldung muss ebenfalls eine Lösung für eine einheitliche Abmeldung in allen Anwendungen gefunden werden. Dazu gibt es sogenannte Push Verfahren mit welcher das Identity Management die Anwendungen über die Benutzerabmeldung informieren kann.

Fazit

Das Thema Authentifizierung / Autorisierung und damit das Thema Sicherheit spielt im Bereich der Microservices eine wichtige Rolle. Bei der Konzeption einer Microservice-Architektur sollte aus meiner Sicht dieses Thema im Vorfeld separat und dediziert geplant werden. Es ist ein zentraler Bestandteil der so genannten Macroarchitektur. Denn jeder Microservices hat zur Aufgabe die Geschäftslogik entsprechend der Nutzerrechte zu gestalten. Dafür kann es natürlich nicht für jeden Microservices eine individuelle Sicherheitslösung geben. Die hier vorgestellte Lösung, hat den Vorteil, dass die Verwendung eines JWT und des OAUTH2-Verfahrens sich sehr gut für die Verwendung innerhalb einer Microservices Architektur eignet. Der JWT kann in jeden HTTP Request als Authorization Header mitgesendet werden, sodass ein HTTP REST basierter Microservice diesen auswerten kann. Es sollte allerdings darauf geachtet werden, dass die Anwendungslogik zur Auswertung des Tokens, sich nicht zu stark auf die Struktur des JWT festlegt. Wird diese nämlich im Laufe der Zeit grundlegend geändert müssen sämtliche Microservices angepasst werden. Mit der Auswahl des Frameworks Spring Security, dem OUATH2 Verfahren und dem JSON Web Token ist eine leichtgewichtige Integration sehr gut möglich.

Microservices, Dokumentenmanagement

In diesem Beitrag unserer Blogserie zum Thema Microservices möchte ich die Vorteile dieses Architekturstiles an einem konkreten Beispiel einer Bibliotheksanwendung aufzeigen. Die hier erläuterten Erfahrungen haben wir in unserem Microservices Projekt im Bereich der Nachweissysteme machen dürfen und möchten diese gerne weiter geben.

Im Laufe unserer Arbeit für die Staatsbibliothek sind durch die Fachabteilungen für unterschiedlichste Anwendungen sehr häufig ähnliche oder gar identische Anforderungen genannt worden. Eine sehr oft formulierte Anforderung war das Management von XML-Dateien. Diese sollten in der Regel abgelegt, verändert, validiert, transformiert oder indiziert werden. Zielstellung dieses Verarbeitungsprozess war in der Regel die Präsentation der im XML enthaltenden Daten im Web.

Die klassische Herangehensweise bereits umgesetzter Projekte war hierbei die Evaluierung und Auswahl eines geeigneten Dokumentenmanagementsystems (DMS) und die Umsetzung der fachlichen Anforderungen innerhalb des DMS. Dabei wurden die im Bibliothekswesen sehr verbreiteten Systeme Mycore, Fedora, DSpace oder aber auch XML Datenbanken verwendet. Diese Systeme bieten in der Regel eine maschinelle Schnittstelle um die XML Dateien zu importieren, exportieren und zu manipulieren. Je nach DMS bietet dieses weitere Funktionen, wie zum Beispiel:

 

  • Generierung eines Indexes zur Suche,
  • Generierung einer Webpräsentation,
  • OAI-Schnittstelle,
  • Aufnahme von Metadaten,
  • Rechtemanagement,
  • Clusterbetrieb,
  • Massenverarbeitung

 

Dabei werden die DMS Funktionalitäten entweder direkt durch eine Webpräsentation oder aber durch eine selbst entwickelte Clientanwendung benutzt. Was aber ist nun problematisch oder beziehungsweise waren die negativen Erfahrungen mit solch einem Aufbau?

DMS Zugriff ohne Fassade

DMS Zugriff ohne Fassade

Ein problematischer Punkt war in der Regel ein Versionswechsel des DMS. Am Beispiel der Weiterentwicklung von der Fedora Version 3 zu der Fedora Version 4 ist die Schnittstelle des Fedora 4 Systems nicht kompatibel mit der des Altsystems. Diese fehlende Abwärtskompatibilität verursacht einen hohen Entwicklungsaufwand, sobald die Clientanwendung oder die Webpräsentation, basierend auf Fedora 3, auf ein Fedora 4 System migriert werden soll. Diese Aufwände sind technisch notwendig, bringen dem Anwender aber keine neue Funktionalität. Diese Tatsache macht die Rechtfertigung des entstehenden Aufwandes sehr schwer. Was wiederum dazu führen kann, dass die Gesamtanwendung nicht zeitnah weiterentwickelt werden kann.

Ein weiterer Punkt ist die Tatsache, dass die gesamte Fachlogik sehr häufig ebenfalls mit den Möglichkeiten der Dokumentenmanagementsysteme oder deren technischen Funktionen umgesetzt worden sind. Dies bedeutet, dass zum Beispiel die Art und Weise des Nachweises, die fachliche Objekte und die Workflows dort implementiert worden sind. Nicht nur bei einer inkompatiblen Migration, sondern auch bei einem Wechsel der DMS-Software müssen die fachlichen Objekte und Workflows neu entwickelt werden. Ebenfalls aufführen möchte ich hier die fehlende Nachnutzbarkeit. Werden durch eine andere Fachabteilung ähnliche Anforderungen in einem anderen Projekt geäußert, können die bereits entwickelten Funktionen nicht noch einmal verwendet werden. Dies basiert in der Regel auf der sehr engen Integration von Clientanwendung oder Webpräsentation und DMS. Auch im Betrieb solcher Systeme haben sich problematische Punkte aufgezeigt. Ein Ausfall des DMS hat direkt einen kompletten bzw. teilweisen Ausfall der Webpräsentation zur Folge. Eine Veränderung der Konfiguration der DMS-Komponente hat ebenfalls direkte Auswirkungen auf die Webpräsentation. Wartungsarbeiten am DMS bedeuten in der Regel einen Ausfall der Webpräsentation.

 

Aber wie kann nun die Microservice-Architektur in den aufgeführten Punkten eine mögliche Lösung darstellen?

 

Um mögliche Inkompatibilitäten zwischen Versionen eines Dokumentenmanagementsystems oder gar einen Wechsel eines Produktes zu ermöglichen, muss die Clientanwendung oder Webpräsentation von der Dokumentenmanagementsoftware entkoppelt werden. Im Bereich der Softwarearchitektur gibt es dafür eine Lösung, die als Fassade bezeichnet wird. Diese wird zwischen der Clientanwendung und dem DMS aufgebaut. Vorteil dieser Fassade ist es, dass diese jegliche Änderungen der DMS Komponente für die Clientanwendung unsichtbar werden lässt. So muss die Clientanwendung nicht mit jeder Änderung des DMS Systems angepasst werden und kann ausschließlich die fachlichen Objekte und Workflows umsetzen.Was aber hat diese Vorgehensweise mit der Microservice-Architektur zu tun? Bis zu diesem Punkt der Erläuterung, nichts. Setzt man nun aber diese Fassade als Microservice um, gewinnt man auf Seiten der Clientanwendung weitere Vorteile.

 

  • Als Microservice kann die Fassade sehr einfach skaliert und somit vielen Anwendungen zur Verfügung gestellt werden.
  • Als Microservice ist ein Zugriff auf das DMS gegen Netzwerklatenzen gesichert. Für die Zugriffe werden Metriken generiert. Diese können bewertet und ins Monitoring eingebunden werden.
  • Als Microservice kann die Fassade unabhängig von den Clientanwendungen weiterentwickelt werden. Während die Fachlichkeit von einem Entwicklerteam entwickelt wird, kann die Integration eines neuen DMS von einem anderen Team gleichzeitig entwickelt werden. So konnten wir im Laufe unseres Projektes drei unterschiedliche Ablagesysteme in der Fassade integrieren, ohne die Clientanwendung anpassen zu müssen.
  • Als Microservice bietet die Fassade eine hohe Nachnutzbarkeit integrierter DMS. Aufgrund der Vereinheitlichung der Schnittstelle können die unterschiedlichsten Clientanwendungen die Ablagesysteme und deren Funktionen nutzen.
  • Als Microservice kann eine Migration bzw. ein Wechsel des DMS ohne Aufwand im Bereich der Clientanwendung durchgeführt werden.
  • Als Microservice können alle Clientanwendungen von der Weiterentwicklung der Fassade profitieren. Wird ein neues DMS integriert, entsteht der Entwicklungsaufwand nur einmal. Dies bedeutet für alle anderen Clientanwendungen eine deutlich kürze Entwicklungszeit.
DMS Zugriff mit Microservice

DMS Zugriff mit Microservice

 

All diese positiven Auswirkungen dieser Architektur haben natürlich auch ihre Herausforderungen. Wir haben die Erfahrung gemacht, dass, sobald das DMS eine REST- Schnittstelle zur Steuerung bietet, der Aufwand der Integration sehr gering ist. Bietet das DMS hingegen keine REST-Schnittstelle so steigt der Integrationsaufwand. Eine weitere  Herausforderung bei dieser Vorgehensweise ist die Schaffung und Weiterentwicklung der einheitlichen Schnittstelle der DMS-Fassade. Diese muss die unterschiedlichen Adressierungen und Steuerungsmöglichkeiten aller DMS zu einem Standard-API zusammenführen. Um alle Möglichkeiten der Microservice-Architektur nutzen zu können, müssen die bereits vorgestellten „Platform Services“ aufgebaut und betrieben werden. Dies vereinfacht zwar den Betrieb, bedeutet initial aber einen Mehraufwand.

 

Fazit

In Anbetracht der aufgezeigten Vorteile fällt mein Feedback zur Microservice-Architektur im Ergebnis positiv aus. Mit sorgfältiger Planung lassen sich die Herausforderungen dieser Architektur meistern. Der initiale Mehraufwand ist meiner Meinung nach mit dem geringeren Aufwand im Dauerbetrieb zu rechtfertigen. Allerdings fehlen zum heutigen Zeitpunkt  noch die Langzeiterfahrung im produktiven Betrieb einer Microservice-Architektur. Aus diesem Grund  würde ich mich sehr über einen Erfahrungsaustausch zum Thema Microservices im Produktionsbetrieb oder ein Feedback zu diesem Beitrag freuen.

Events

Beyond “Willkommenskultur”. Podiumsdiskussion am 28.2.

Beyond Willkommenskultur – Artistic and Academic Approaches to Integration from a Transatlantic Perspective. Podiumsdiskussion in deutscher und englischer Sprache

  • Termin

    Mi 28. Februar 2018
    18 Uhr

  • Veranstaltungsort

    Staatsbibliothek zu Berlin
    Dietrich-Bonhoeffer-Saal
    Potsdamer Straße 33
    10785 Berlin

  • Anfahrt

    S + U Potsdamer Platz

    Bushaltestelle
    H Potsdamer Brücke (Bus M29)
    H Varian-Fry-Straße (Bus 200)
    H Kulturforum (Bus M48)

  • Alle Veranstaltungen

    Klicken Sie hier um zu einer Übersicht unserer Veranstaltungen zu gelangen.





Rückschau auf die Veranstaltung


Podiumsdiskussion
Beyond „Willkommenskultur“ – Artistic and Academic Approaches to Integration from a Transatlantic Perspective

Grußwort: Barbara Schneider-Kempf, Generaldirektorin der Staatsbibliothek zu Berlin

Moderation: Pamela Rosenberg, Michael P. Steinberg

In Kooperation mit der American Academy in Berlin
Die Veranstaltung findet in englischer und deutscher Sprache mit Simultandolmetscher statt.

Mittwoch, 28. Februar 2018
18 Uhr

Eintritt frei

Staatsbibliothek zu Berlin
Dietrich-Bonhoeffer-Saal
Potsdamer Str. 33
10785 Berlin

Weitere Informationen und Anmeldung (Seiten der American Academy in Berlin)