Beiträge zu Innovationen in unserem IT-Bereich

Relaunch der Digitalisierten Sammlungen

Formate, Bilder, Sicherheit – Die neue Beta der Digitalisierten Sammlungen

Meistens läuft ein Update unserer Digitalisierten Sammlungen eher still ab. Neue Features werden eingespielt, Bugs werden gefixt und intern wird getestet. Tagesgeschäft halt. Inzwischen ist aber soviel passiert, dass wir etwas umfangreicher davon erzählen wollen. Und wir möchten alle NutzerInnen dazu einladen zu testen, Fehler zu finden und Anmerkungen zu geben. Denn die Beta soll bald produktiv gehen und die neuen Features für alle zur Verfügung stehen, damit im Anschluss die neue Beta entstehen kann.

Alles sicher

Die Digitalisierten Sammlungen wurden komplett auf https – also eine sichere, verschlüsselte Verbindung – umgestellt. Das haben wir erst mit dem Beta-Portal getestet, fanden es aber so wichtig, dass wir es auf dem produktiven Portal ebenso implementiert haben. Die Umstellung betrifft nicht nur den Server der die Präsentation an sich ausliefert, sondern auch den Content-Server, der für die Auslieferung unserer Bilder zuständig ist, sowie weitere Hintergrunddienste.

Alle nun folgenden Änderungen kann man hingegen nur unter dieser Adresse ausprobieren:

 

 

Bildauslieferung nach iiiF-Standard

Es beginnt mit dem Content-Server – dieser wurde neu entwickelt. Der bisherige Content-Server war mit dem Framework Node.js® umgesetzt. Bei der Neuimplementierung haben wir uns ebenfalls für diese Technologie entschieden und auf das Web Framework koa aufgesetzt.
Der Hauptgrund für die Umstellung war die Anpassung der Auslieferung der Bilder mittels des relativ neuen iiiF-Standards. Das International Image Interoperability Framework™ ist ein internationaler Standard für den Zugriff auf Bilder und das Handling der Metadaten für diese Bilder. Das erlaubt uns unsere Bilder und Metadaten noch besser mit anderen Institutionen teilen zu können, sofern diese ebenfalls auf diesen Standard setzen, was immer mehr Institutionen weltweit machen. Weiterhin erlaubt der Einsatz von Standards eine Nutzung von weiteren Projekten, die diesen Standard implementieren, wozu bspw. der iiiF-Viewer Mirador gehört.
Unser Content-Server kann etwas mehr, er implementiert neben der iiiF Image API eine Reihe weiterer Funktionen, die speziell zu unserem Stack der Digitalisierten Sammlungen gehören.
Das Beispiel zeigt ein auf 500 Pixel Breite verkleinertes Bild, das um 90 Grad gedreht in Graustufen ausgeliefert wird. Einen kurzen technischen Einblick erhält man in der NGCS routes Dokumentation, eine tiefer gehende Betrachtung der technischen Umsetzung innerhalb der Software, ist einen eigenen Beitrag wert.

Mehr Werkzeuge

Klicken Sie auf das Bild, um die Bildfilter jetzt zu testen.

Unser Werkzeugkasten hat sich erweitert. Neben einem zusätzlichen Zoom-Slider bieten wir nun einen eigenen Bereich für Bildmanipulationen. Damit lässt sich das Bild auf vielfältige Weise neu erforschen: bestimmte Bereiche können durch eine Erhöhung des Kontrastes verdeutlicht, Farben zur Veränderung des Gesamteindruckes angehoben oder abgeschwächt werden. All diese Veränderungen können für das einzelne Werk gespeichert werden und gelten dann für jedes weitere Bild, das über die Navigation innerhalb dieses Werkes aufgerufen wird.

Neuer Download-Bereich

Viele NutzerInnen wollen nicht nur online durch unsere Werke stöbern, sondern sich die Digitalisate in voller Qualität auch auf den eigenen Rechner laden. Der hierfür vorgesehene Downloadbereich ist mittlerweile so umfangreich geworden, dass er einen eigenen View verdient hat. Das neue Icon ist nach der häufigsten Anfrage an unseren Support benannt: “Wo befindet sich der PDF-Download?”, und nun hoffentlich gut genug in Szene gesetzt.

Der PDF-Download selbst hat derzeit noch kein Face-Lifting erhalten und ist weiterhin eine Client-seitige Lösung, was bedeutet: welche Anzahl und wie groß die Bilder innerhalb des PDFs sein können, hängt in großem Maße von dem Rechner ab, an dem man den PDF-Download startet. Weiterhin gibt es wie gewohnt die unkomplizierte Möglichkeit sich alle Bilder oder einzelne Abschnitte in hoher Qualität als ZIP-Datei herunterzuladen und damit selbst die Formate auf seinem Rechner zu erstellen, die für die eigene Arbeit gewünscht werden.

Neben der METS-Datei, die alle Metadaten enthält, ist es nun auch möglich diese als iiiF Manifest abzurufen. Dieses im JSON-LD Format gehaltene Dokument entspricht der iiiF Presentation API und bringt unsere Metadaten in neuer Form in die Welt. In iiiF kompatiblen Viewern, wie Mirador, können URI’s zu dem Manifest geladen und damit unsere Werke dort angezeigt werden, was viele neue Blickwinkel auf unsere Digitalisate eröffnet – insbesondere der direkte Vergleich von Seiten, Illustrationen oder ganzen Werken.

Wenn uns der OCR-Text zum Werk vorliegt, erscheinen drei weitere Download Links, einmal der Download der OCR der einzelnen Seite, der Download des gesamten Werkes im ALTO XML Format, sowie der gesamte Text des Bandes als einfache Text-Datei(.txt). Gerade die Letztere war ein vielfacher Wunsch, da sich dieser Text nicht nur einfach lesen und in den bevorzugten Editor einfügen lässt, auch Text-Mining-Projekte freuen sich über einfachen Text zur Verarbeitung. Weiterhin auf unserer Liste der geplanten Funktionen ist das Angebot von strukturiertem TEI.

Die jeweilige Lizenz der Werke findet sich ebenfalls sehr präsent im Download-View, sowie auf dem Info-View und dem PDF-Deckblatt. Unsere gemeinfreie Werke werden derzeit schrittweise auf eine Public-Domain-Auszeichnung umgestellt. Damit die Umgewöhnung für alle Nutzer leicht fällt, ist die komplette Download-Sektion für eine Übergangszeit im alten Toolbox-View gespiegelt.

Mehrsprachigkeit

Die Weboberfläche ist ab jetzt ebenso in Englisch verfügbar. Neben den Bedienflächen sind auch viele der Fachbegriffe übersetzt. Das schließt neben den Kategorien und Strukturtypen, in die sich unsere Digitalisierten Sammlungen gliedern, auch die einzelnen Standardelemente der Werke in den Inhaltsverzeichnissen und weitere Metadaten mit ein. Die eigentlichen Inhalte, wie Titel, Text und Autor, werden weiterhin in der Orginalsprache angezeigt.

Testen, testen, testen

Alle unsere neuen Funktionalitäten sind mit Softwaretests hinterlegt und in unsere Continuous IntegrationContinuous Deployment (CI / CD) – Strecke eingebunden. Wir tun unser Möglichstes, um die neuen Features fehlerfrei auszuliefern – aber es gibt auch andere Aufgaben und Projekte und damit eine begrenzte Zeit, die investiert werden kann. Deshalb an diese Stelle unsere Bitte: Probieren Sie unser neues Angebot aus und geben Sie uns hierzu Rückmeldungen. Wir freuen uns über alle Meinungen, positives wie negatives Feedback und natürlich über die Fehler, die wir nicht gefunden haben.

Neben diesem einleitenden Blogposting veröffentlichen wir dazu noch ein zweites, in dem ganz nüchtern alle Bereiche einzeln verzeichnet sind, in denen sich die aktuelle Beta von der Produktivinstanz unterscheidet. Entlang dieser Liste kann man testen – und dann unter diesem zweiten Artikel in den Kommentaren Rückmeldungen hinterlassen.

 

Neue Funktionen in der Beta der Digitalisierten Sammlungen

Die folgenden Neuentwicklungen und Anpassungen haben Einzug in die Beta-Version der Digitalisierten Sammlungen gefunden. Über Feedback und Anmerkungen zu https://digital-beta.staatsbibliothek-berlin.de freuen wir uns: nutzen Sie dafür bitte das Kommentarfeld unter diesem Beitrag. Eine ausführliche Beschreibung der neuen Funktionen finden Sie im Beitrag Formate, Bilder, Sicherheit – Die neue Testversion der Digitalisierten Sammlungen.

Release 1.1.0 – 19.12.2018

    • Die Auslieferung der Bilder erfolgt jetzt über den neuen Content-Server im iiiF-Standard.
  • Die Weboberfläche ist nun wahlweise in Englisch verfügbar. Neben den Bedienflächen sind viele der Fachbegriffe übersetzt.
  • Der bekannte Toolbox-View enthält nun die folgenden neuen Möglichkeiten:
    • eigener Zoom-Slider
    • Bildfilter (Helligkeit, Kontrast, Sättigung, Invertierung)
    • Speicherung der Bildanpassungen (Zoom, Drehung, Filter) innerhalb eines Werkes beim Blättern
  • Neuer Download-View mit folgenden Optionen:
    • JPG-Datei der Seite
    • IIIF-Manifest
    • OCR-Datei der Seite
    • ZIP-Archiv der OCR Dateien
    • OCR des Bandes als Text (.txt)
  • Die Lizenz des jeweiligen Werkes finden Sie jetzt:
    • im Download-View
    • im Info-View
    • auf dem Deckblatt des PDF
  • Die Lizenz gemeinfreier Werke werden nun endlich auf Public Domain Mark 1.0 umgestellt. Der Prozess ist noch nicht für alle Werke abgeschlossen.
  • Wenn man am Ende einer Trefferseite zur nächsten Ergebnisseite blättert, wird nun auf den Anfang der nächsten Trefferseite gesprungen (nicht wie bisher das Ende).
  • Fehler bei der Sortierung von Trefferlisten wurden behoben.
  • Die Ansicht des vollständigen Inhaltsverzeichnisses wurde um die neuen Download-Möglichkeiten ergänzt.
  • Maximaler Zoom-Grad für die Betrachtung der Einzelbilder erhöht, insbesondere im Vollbild-Modus.

 

 

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.