Beiträge

Wissenschaftliche Bibliotheken und Stadtentwicklung

Frau Eva May, Mitarbeiterin im FID-Projekt der Kartenabteilung, bekommt den renommierten b.i.t.online-Innovationspreis 2017 verliehen, welcher jedes Jahr drei herausragende Abschlussarbeiten aus dem Bereich Bibliothek, Information und Dokumentation auszeichnet. Die von ihr eingereichte Arbeit „Wissenschaftliche Bibliotheken und Stadtentwicklung“ zeigt die zentrale Rolle, die wissenschaftliche Bibliotheken in Diskurs und Praxis der Stadtentwicklung spielen können. Anhand von verschiedenen internationalen Beispielen wird gezeigt, welche Chancen und Risiken die Implementierung in die Stadtentwicklung nicht nur für die öffentlichen, sondern speziell auch für die wissenschaftlichen Bibliotheken birgt. Die Einbeziehung letzterer in die Stadt stellt eine bislang noch neue Entwicklung dar, zu der bisher wenig geforscht wurde.

Mit freundlicher Genehmigung Dinges und Frick

Der Preis ist mit 500 Euro dotiert und wird beim Deutschen Bibliothekartag 2017 in Frankfurt am Main bei der Veranstaltung „Innovationsforum“ am 1. Juni 2017 vorgestellt. Die preisgekrönte Arbeit wird in der Reihe „BIT online / Innovativ“ im Verlag Dinges & Frick Wiesbaden veröffentlicht. Wir gratulieren herzlich!

Johannes Block aus Pommern – der stumme Prediger und seine sprechende Bibliothek

Auch in der Staatsbibliothek des 21. Jahrhunderts sind noch Entdeckungen möglich. So staunte Falk Eisermann, der Leiter des Inkunabelreferats, nicht schlecht, als er im Magazin auf den Namen eines alten Bekannten aus dem 16. Jahrhundert stieß. Eigentlich wollte er nur zwei Inkunabeln ausheben, um sie einer Seminargruppe als Studienobjekt zu präsentieren. Ihn interessierte vor allem eine Cicero-Ausgabe von 1465 aus der Mainzer Offizin Peter Schöffers (GW 6921), an die ein Rostocker Druck des Vinzenz von Beauvais von 1477 angebunden ist (R 358). Der Besitzvermerk Liber Johannis Block presbyteri Caminensis diocesis predicatoris machte den Fachmann für alte Bücher stutzig. Konnte es sein, dass der Kamminer Priester mit dem Prediger und Reformator Johannes Block identisch war, den Eisermann als Buchbesitzer aus der Kirchenbibliothek Barth kannte?

Der Barther Reformator Johannes Block. Bild von der Predigtkanzel der Marienkirche Barth (um 1580). Foto: Eva Wunderlich. Lizenz: CC-BY-NC-ND (3.0)

Dieser Johannes Block aus Barth ist eine rätselhafte und zu Unrecht unterschätzte Figur. Als Zeitgenosse, teilweise auch als Protegé der Wittenberger Reformatoren Martin Luther und Johannes Bugenhagen hat er die pommersche Herzogsstadt Barth reformiert. In Kirchenakten ist er aber kaum bezeugt. Leider hat er auch keine eigenen Schriften hinterlassen. Niemand hat sich die Mühe gemacht, auch nur eine seiner Predigten aufzuzeichnen. So wäre Block heute vergessen, hätte er nach seinem Tode nicht seine Gelehrtenbibliothek der Barther Marienkirche überlassen. Glücklicherweise hat Block in seinen Büchern teilweise seine Lebensstationen und Berufe notiert. Sie verraten, dass er nicht nur in Pommern gewirkt, sondern auch zu den frühesten Wanderpredigern in Preußen, im Baltikum und in Finnland gehört hat.

Ein weiteres Glück war, dass Eisermann wusste, dass der Verfasser dieses Blog-Beitrags seit 20 Jahren an der Rekonstruktion von Blocks Bibliothek arbeitet. Ein kurzer Anruf, einige gepostete Bilder und eine Autopsie des Bandes brachten schnell Gewissheit: Die beiden Blocks waren identisch. Damit war aber auch ein guter Anlass entstanden, einen Block-Blog von der Staatsbibliothek Berlin aus zu schreiben. Immerhin hatte man gemeinsam das einzige Buch identifiziert, das von Blocks Prädikantenbibliothek außerhalb Barths erhalten geblieben ist.

“Zeig mir Deine Bücher – ich erzähl’ Dein Leben!”

Diese Identifikation ist bedeutsam, weil Blocks Büchersammlung einen großen historischen Zeigewert hat. Sie ist eine der ganz wenigen intakten Privatbibliotheken der Lutherzeit und vermittelt wertvolle Einblicke in die Entstehung der evangelischen Bewegung im Ostseeraum. Aus ihr wird deutlich, wie auch fernab der Wittenberger “Zentrale” evangelische Prädikanten am Werk waren, die als Leuchttürme des neuen Glaubens eigene Ideen von “Reformation” prägten und verbreiteten.

Von dieser wertvollen Bibliothek, die von der Universitätsbibliothek Greifswald inzwischen digitalisiert wurde, sind heute noch 125 Bände erhalten. Sie überliefern, zum Teil in Sammelbänden, acht Handschriften, 50 Inkunabeln und über 220 Frühdrucke. Das ist eine stattliche Sammlung, die Anfang des 16. Jahrhunderts dem Bestand einer kleineren Klosterbibliothek entsprach. Als Berufsbibliothek war Blocks Büchersammlung sein wichtigstes Arbeitswerkzeug. Sie spiegelt, wie Block auf seiner Stellensuche von Stadt zu Stadt zog, wie er als Prädikant an Kirchen installiert wurde und wie er sich gegenüber Bettelmönchen und Weltgeistlichen auf dem “Markt der Frömmigkeit” behaupten konnte – vor und nach seinem Übergang zur Reformation. Insofern bietet seine Predigerbibliothek einzigartige Einblicke in die Denk- und Arbeitsmuster der neuen, seit dem 15. Jahrhundert nachweisbaren Berufsgruppe der Prädikanten.

Predigerbibliothek des Johannes Block als Teil der Barther Kirchenbibliothek. Foto: Eva Wunderlich. Lizenz: CC-NY-NC-ND (3.0)

Blocks reisende Gelehrtenbibliothek bildet heute den wertvollsten Kern der 1398 erstmals erwähnten Barther Kirchenbibliothek. Sie befindet sich heute als separierter Bereich innerhalb des historischen Gesamtbestandes der Marienkirche von knapp 4000 Bänden. Diese ist die mutmaßlich älteste, am Ursprungsort enthaltene kirchliche Büchersammlung Deutschlands, wo die Bücher heute noch im gotischen Bibliotheksraum stehen, in dem die Geistlichen, Lehrer und Schüler des Mittelalters studiert und gearbeitet hatten.

St. Marien Barth, Wirkungsort Blocks als pommerscher Reformator (1534-1544/45). Foto: Jürgen Geiß-Wunderlich. Lizenz: CC-NY-NC-ND (3.0)

In fast jedem von Blocks Büchern findet man Kauf- und Besitzvermerke von seiner Hand. Sie informieren über Ort und Zeit der Erwerbung, aber auch über die Kaufpreise. Dazu lassen sich vielfach Buchbinder, Sammlungskontexte (zumeist wurden mehrere Drucke in einen Band gebunden), Illuminatoren und Rubrikatoren sowie (über die handschriftlichen Anmerkungen) der Umgang Blocks mit seinen Büchern rekonstruieren. Man erhält so Auskunft über die Vertriebs- und Handelswege der Bücher und deren Verwendung. Erkennbar wird vor allem das Vertriebsnetz des Buchhandels, das sich im Falle Blocks von Italien, Südwestdeutschland und Frankreich, wo die Bücher zumeist gedruckt wurden, über Flandern, die Niederlande und das “Wendische Quartier” der Hanse (zwischen Lübeck und Stettin) bis in den nördlichen Ostseeraum zieht, wo die Bücher schließlich illuminiert, gebunden und verkauft wurden.

Besitzvermerk des Kamminer Klerikers Johannes Block (Dorpat, 1514/20) in einer Predigtausgabe der Barther Kirchenbibliothek, 4° E 13, 1r. Foto: Eva Wunderlich. Lizenz: CC-NY-NC-ND (3.0)

Dramatisches Leben in einer Zeit des Umbruchs

Da Blocks Lebensweg den Handelswegen der deutschen Kaufleute im Ostseeraum folgte, wo er als Prediger wohl auch seine follower – d.h. seine Zuhörer und Anhänger – fand, lässt sich in kriminalistischer Kleinarbeit ein Geschichtspuzzle um den Wanderprediger aus Pommern zusammensetzen. Dabei bietet Blocks Prädikantenbibliothek ein von Aufbrüchen und Schicksalsschlägen gezeichnetes Lebensbild. Dieses ist beeindruckend und aufschlussreich zugleich, denn Lebensbrüche sind geradezu zum Signum der ersten Reformatorengeneration geworden – man denke nur an die großen Namen Martin Luther, Thomas Müntzer, Andreas Bodenstein (Karlstadt) und Huldrych Zwingli.

Folgen wir den Kauf- und Besitzvermerken in Blocks Büchern, so beginnt sein Lebensweg in Stolp (heute Slupsk/Polen) in Hinterpommern, wo er um 1470/80 geboren wurde. Im geistigen Umfeld des pommerschen Humanisten Bugenhagen kam Block in den 1490er-Jahren als junger Kaplan und Kleriker der Diözese Kammin (Cammin, heute Kamien Pomorski/Polen) mit dem niederländischen Schulhumanismus in Berührung – dem damals fortschrittlichsten Curriculum nördlich der Alpen. Danach zog er dann als gut ausgebildeter Prediger in Richtung der großen Handels- und Hansestädte im Osten. 1512-1513 ist er kurz in Danzig (heute Gdansk/Polen) bezeugt. Hier, auf der wichtigsten Drehscheibe des Ostseehandels, bemühte er sich erfolglos um eine Anstellung. Ab 1514 taucht er in der Hansestadt Dorpat (heute Tartu/Estland) auf. Diese Stadt bildete mit Riga und Reval (heute Tallinn/Estland) das Dreigestirn der großen, von deutschsprachigen Fernhändlern dominierten Handelsmetropolen in Livland.

Im Gebiet des heutigen Lett- und Estland lag in den 1520er-Jahren eine der religiösen “Boomregionen” Europas. Die Christianisierung war in Livland später eingeführt worden als im Heiligen Römischen Reich, so dass die Saat Luthers hier auf fruchtbaren Boden gefallen war. Nicht wenige Wanderprediger erprobten hier, unterstützt durch die deutschsprachigen Kaufleute (vor allem die Gilden der “Schwarzhäupter”), die Reformideen aus Wittenberg. In den 1530er Jahren trug man den neuen Glauben dann wieder zurück nach Deutschland. Luther hat allerdings auch Gefahren der Verbreitung “seiner” Reformation in Livland gesehen. Anfang der 1520er-Jahre schrieb er sorgenvolle Sendbriefe an den Magistrat von Riga, aus denen klar wird, dass er selbst den Einfluss Wittenbergs für begrenzt hielt. Sorge bereiteten Luther “Schwärmer” wie der Wanderprediger Melchior Hofmann, ein Kürschner aus Schwäbisch Hall, der in Livland um 1525 mehrere Bilderstürme anzettelte, so dass man ihn in Wittenberg schnell wieder fallen ließ. Doch die tatsächlichen Zusammenhänge sind schwer zu beurteilen, da die Quellenlage – vor allem in Dorpat – desaströs ist. So waren Wissenschaftler aus Estland elektrisiert, als sie auf Blocks Predigerbibliothek aufmerksam wurden. Schnell war klar, dass die Lebensgeschichte dieses “stummen Predigers” – nicht nur für Livland – einen missing link der frühen Reformationsgeschichte Europas darstellt.

Blocks Besitzvermerke zeigen, dass er erst in Livland wirklich Karriere machte. In Dorpat wurde er um 1520 als Prädikant an der Stadtpfarrirche St. Marien angestellt; gleichzeitig erhielt er eine Stelle als Prediger an der Kathedrale auf dem Domberg. Ungefähr zeitgleich trat Block unter dem Einfluss des Humanisten Erasmus von Rotterdam und des frühen Luther zur Reformation über. Das verraten seine in den Jahren 1518 bis 1524 erworbenen Bücher. Die Reformation kostete den Dorpater Prediger jedoch seine Existenz, denn im Chaos des Bildersturms von 1524/25 verlor er beide Predigerstellen. Block war offenbar zwischen die Mühlsteine des Stadtrats und des Dorpater Bischofs Johannes Blankenfeld geraten, der in Personalunion als (Erz-)Bischof von Riga, Reval und Dorpat einer der mächtigsten Herren Livlands war. Beide Akteure zerfleischten sich in ihrem Kampf um die politische Vorherrschaft in der Stadt mit ihrem riesigen Hinterland. Die Reformation, vor allem die Frage, wer den Klerus kontrollierte und von den materiellen Gütern der Kirche profitieren konnte, war zu einem Politikum geworden, über das auch der Dorpater Prediger Block stolperte – und schließlich fiel.

Schlosskirche in Wiburg/Südostfinnland, Wirkungsort Blocks 1528-1532. Foto: A. Savin (Wikimedia Commons). Lizenz: CC-BY-NC-ND (2.5)

Nach seiner Entlassung schien Blocks Karriere in Dorpat erst einmal beendet. Fünf Jahre hielt er noch in der konfessionell zerrissenen Stadt aus. In dieser Situation erreichte ihn ein Angebot des Grafen Johannes von Hoya – aus Finnland. Der Adelige residierte in der von deutschen Kaufleuten dominierten Handelsstadt Wiburg (Viipuri/Finnland, heute Wyborch/Russland) und suchte einen Prediger. Block schien ihm dafür der geeignete Mann gewesen zu sein. Ab 1528 diente er Hoya als erster evangelischer Prädikant, der in Finnland bezeugt ist. Vermutlich war er auch an der als “Kaderschmiede” berühmten Wiburger Lateinschule tätig, wozu ihn seine Bücher sicherlich befähigten. Im Ankunftsjahr Blocks in Wiburg (1528) hatte der bisherige Schulrektor, der Däne Clemens Erasmi, die Stadt in Richtung der alten Bischofsstadt Turku (Abo) verlassen. Vermutlich hat ihn Block als Schulleiter ersetzt. Erasmi nahm seinen besten Schüler Michael Agricola mit, der später in Diensten des schwedischen Königs Gustav Wasa zum Reformator Finnlands werden sollte. Dass auch Block zur Gruppe der ersten Reformatoren Finnlands – wenn auch mit einer anderen Ausrichtung – zählte, war bislang unbekannt, denn auch hier sind die Quellen für die Zeit bis zur Mitte des 16. Jahrhunderts rar.

Leider ereilte Block in Wiburg das gleiche Schicksal wie in Dorpat. Sein Dienstherr Hoya kontrollierte von seinen Festungen Savonlinna im mittelfinnischen Seengebiet und Wiburg an der Küste einen Machtbereich, der ganz Ostfinnland (Karelien) umfasste. In dieser Funktion war der Graf schon bald in das Fadenkreuz seines Schwagers (!) Gustav Wasa geraten. Der schwedische Regent nutzte die Reformation vom westfinnischen Turku aus für eine Expansionspolitik Richtung Osten aus. Dem stand der Wiburger Graf im Weg und somit wurde auch Blocks Lage prekär.

Geleitbrief von Graf Johannes von Hoya für seinen Prediger Johannes Block (Wiburg/Finnland, 15. August 1532). Riksarkivet Stockholm, Strödda historiska handligar 1a. Foto: Riksarkivet Stockholm. Lizenz: CC-NY-NC-ND (3.0)

Der Wiburger Prediger scheint die von der schwedischen Krone ausgehende Gefahr erkannt zu haben und reagierte geistesgegenwärtig: Ausgestattet mit einem Geleitbrief seines Dienstherren setzte er sich Mitte August 1532 in seine Heimat ab. Hoya hingegen musste dem politischen Druck nachgeben und ging 1533 nach Reval ins Exil. Block hingegen befand sich in seiner Heimat Pommern in relativer Sicherheit. Doch anerkannt war er noch keineswegs. Zu Beginn der Fastenzeit 1533 musste er seine erste reformatorische Predigt auf dem Friedhof des Hospitals St. Jürgen vor den Toren Barths abhalten, vor einer Zuhörerschaft aus Pestkranken und Tagelöhnern, die kein Bürgerrecht in der Stadt hatten. Mehr als eine derartige “Sondierungspredigt” war vor Einführung der Fürstenreformation in Pommern kaum möglich.

Pestspital St. Jürgen bei Barth (um 1980), erster Wirkungsort Blocks als Prediger in Pommern (1533). Foto: Chron-Paul (Wikimedia Commons). Lizenz: CC-BY-SA (4.0)

Block riskierte es tatsächlich, noch einmal nach Finnland zurück zu gehen. Hier gelang es ihm, seine Frau (er hatte sie in Liv- oder Finnland geheiratet) aus dem zusammenbrechenden Wiburg heraus zu holen. Auch seine Büchersammlung, die zu diesem Zeitpunkt etwa 90 Bände umfasste, konnte Block evakuieren. 1534 war er wieder in Pommern, wo die Herzöge mit Bugenhagens Hilfe inzwischen die Reformation eingeführt hatten. Von der Barther Marienkirche aus diente Block der Fürstenreformation als oberster Prädikant und evangelischer Pastor bis zu seinem Tode (1544/45).

Das Buch der Staatsbibliothek kommt zu Wort

Wie lässt sich die Bedeutung des Berliner Bandes aus Blocks Bibliothek nun einordnen? Der Codex kann erst nach 1514 in seinen Besitz gekommen sein. In diesem Jahr stockte Block seine Kamminer Pfründe von 4 auf 80 Mark (!) jährlich auf, wie eine kürzlich in der Staatsbibliothek entdeckte Quelle belegt. Ferner wird Block im Berliner Band als Prediger Dorpats bezeichnet (die Passage predicator[is] T[arbatensis] ist am Ende durch Ausriss kaum lesbar), so dass er es vor seiner Entlassung um 1524/25 erworben haben muss.

Pründenvermerk des Kamminer Klerikers Johannes Block. Staatsbibliothek zu Berlin – Preußischer Kulturbesitz, Handschriftenabteilung, Ms. boruss. fol. 97, 28r. Foto: Jürgen Geiß-Wunderlich. Lizenz: CC-NY-NC-ND (3.0)

Der Band mit den beiden Inkunabeln, den Block 1514/25 in Dorpat in einem soliden Holzdeckeleinband kaufte, war bereits “antiquarisch”, denn die beiden Drucke waren schon 40 bis 50 Jahre auf dem Markt. Block erwarb hier mit ‘De officiis’ und den ‘Paradoxa stoicorum’ zwei Lehrschriften des antiken Staatsmanns und Philosophen Cicero (Mainz, 1465), dazu den Fürstenspiegel ‘De regimine principum’ des französischen Dominikaners Vinzenz von Beauvais (Rostock, 1477). Beide Ausgaben – Cicero wie Vinzenz von Beauvais – sind über die Digitalen Sammlungen der Berliner Staatsbibliothek zugänglich.

Der Buchschmuck ist – wie damals üblich – per Hand in die gedruckten “Rohlinge” eingemalt. Der Verfasser dieses Blogs hat ähnliche Belege aus Stralsund gefunden, so dass der Band dort verkaufsfertig gemacht und mit den Livlandfahrern nach Dorpat exportiert worden sein dürfte. Hier fügte er sich in Blocks Bibliothek gut ein, die um 1515/20 vor allem aus humanistischer Gelehrten- und spezialisierter Predigtliteratur bestand. Blocks Umgang mit Cicero und Vinenz von Beauvais zeigt das Selbstbewusstsein des humanistischen Gelehrten, der schon in seiner Jugend Griechisch gelernt hatte und die griechischen Passagen in seinem Cicero lesen und verstehen konnte. Dazu glossierte er in Humanistenart den Text, indem er zwischen den Zeilen sprachliche Synonyme eintrug. Humanistisch sind auch seine Querverweise auf den Kirchenvater Augustinus und auf das historiographische Werk des in Deutschland damals populären Humanisten Enea Silvio Piccolomini.

Eingangsseite von Blocks Cicero-Druck von 1465. Staatsbibliothek zu Berlin – Preußischer Kulturbesitz, Handschriftenabteilung, Inc. 1515,5, 1r. Foto: Jürgen Geiß-Wunderlich. Lizenz: CC-NY-NC-ND (3.0)

Ein Rätsel bleibt, wie und wann der Codex aus Barth nach Berlin gelangt ist. Laut Akzessionsvermerk und einem (ziemlich unsensibel) in die Eingangsinitiale gestempelten Besitzvermerk wurde der Band 1912 regulär von der Königlichen Bibliothek erworben. Die beiden wertvollen Inkunabeln – vor allem der berühmte Schöffer-Druck von 1465 – haben die Barther Kirchengemeinde wohl bewogen, den Band zu veräußern. Dass man damit auch ein Zeugnis der eigenen Vergangenheit verkaufte, war den damaligen Hütern der Kirchenbibliothek nicht bewusst. Auch deshalb ist man froh, dass der Band des “stummen Reformators” aus Pommern in Berlin erhalten geblieben ist.

Ein wissenschaftlicher Katalog der rekonstruierten Bibliothek Blocks wird vom Verfasser dieses Blogs vorbereitet. Er soll im Herbst oder Winter 2017 bei der Evangelischen Verlagsanstalt Leipzig erscheinen. Dem Katalog beigegeben sind die Beiträge einer Fachtagung mit Geschichts-, Buch- und Reformationswissenschaftlern aus Deutschland, Finnland, Estland und der Schweiz, die im September 2015 am Barther Bibelzentrum stattfand. Zu anderen “Highlights” der wertvollen Büchersammlung von St. Marien sei auf den Band “Einblicke: Bücher aus der Barther Kirchenbibliothek im Fokus” verwiesen, der im vergangenen Jahr erschienen ist.

 

 

 

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.

Microservices, Integration

Die Microservices Architektur bietet den Vorteil der freien Technologieauswahl bei jedem Microservice. Ein wichtiger Punkt unseres Evaluierungsprojektes war die Prüfung der Integrationsfähigkeit von Softwarekomponenten, welche nicht Java, bzw. Spring Cloud im Technologiestack enthalten. Dazu möchte ich in diesem Beitrag unserer Blogserie zeigen auf welche Art und Weise wir legacy Software, wie zum Beispiel Fedora4 Content Repository in die „Platform Service“ der Microservices Welt integriert haben.

 

Integration

Für die Integration solcher “nicht Java basierten Softwarekomponenten” stellt Netflix Open Source Stack (Netflix OSS) das Projekt Prana bereit. Prana ist eine sogenannte Sidecar Anwendung. Durch die Nutzung von Prana ist es möglich die “Platform Service“, wie zum Beispiel Eureka, Circuit Breaker und Ribbon in solchen Projekten zu verwenden. Wie der Name “Beistellwagen” schon verrät wird das Prana Projekt lediglich neben den nicht Netflix fähigen Microservice gestellt und konfiguriert. Wie genau das funktioniert, möchte ich gerne an folgendem konkreten Beispiel demonstrieren.

 

Dazu haben wir im ersten Schritt ein Spring Boot Projekt aufgesetzt und Spring Cloud Sidecar durch folgende Annotation an der “main” Klasse aktiviert.

 

@EnableSidecar

@SpringBootApplication

public class SideCarApplication {

 

public static void main(String[] args) {

SpringApplication.run(SideCarApplication.class, args);

}

}

 

Anschließend müssen im Sidecar Projekt noch folgende Properties gesetzt werden:

 

spring.application.name=Fedora4-Sidecar

server.display-name=Staatsbibliothek Fedora Sidecar

server.port=9080

sidecar.health-uri=http://localhost:8080/rest/health.json

sidecar.port=8080

sidecar.home-page-uri=http://localhost:8080/

 

Mit der Angabe der health-uri wird auf einen REST Endpunkt der Fedora4 Anwendung verwiesen, aus welchem Sidecar die Statusinformation zur Übermittlung an Eureka erhält. Dazu haben wir im Fedora4 folgendes triviales JSON Dokument hinterlegt:

health.json

{“status”:”UP”}

Bei erreichbarem Fedora4 kann Sidecar nun diese Statusinformation an Eureka übermitteln. Sidecar muss auf demselben Server laufen wie Fedora4. Zusätzlich zur Sidecar Konfiguration müssen natürlich noch die Konfigurationswerte für Eureka, Hystrix und Ribbon gesetzt werden. Um Fedora4 in Eureka sichtbar zu machen haben wir daher für die Service Registry folgende Werte gesetzt:

 

eureka.instance.leaseRenewalIntervalInSeconds=10

eureka.client.healthcheck.enabled=true

eureka.client.serviceUrl.defaultZone=http://localhost:8761/serviceregistry/eureka/

eureka.client.registryFetchIntervalSeconds=5

 

Ist Fedora4 gestartet zeigt Eureka die Integration wie folgt an:

fedora-sidecar

Ist das Sidecar Projekt gestartet und verfügbar, kann anschließend Fedora4 über folgende URL angesteuert werden:

 http://<hostname>:9080/fedora4-sidecar/

 

Welche Vorteile bringt uns diese Integration nun aber ganz konkret.

 

  • ohne Fedora4 anpassen zu müssen, lässt es sich in die “Platform Services” von Netflix integrieren,
  • Fedora4 ist damit in der Service Registry sichtbar und abrufbar,
  • ein Aufruf von Fedora4 über die Sidecar URL wird als Circuit Breaker Command ausgeführt,
  • es werden Hystrix Metriken generiert welche im Hystrix Dashboard sichtbar sind,
  • es kann Load Balancing verwendet werden, sobald Fedora4 mehrfach installiert ist,
  • es kann die zentrale Configuration Management Instanz verwendet werden.

 

Obwohl Fedora4 kein Microservice ist können Client Anwendungen die Service Registry nach der Einstiegs URL von Fedora4 fragen. Anschließend wird jede Anfrage der Clients via Hystrix abgesichert und aufgezeichnet. So konnten wir zum Beispiel die Antwortzeiten der Fedora4 REST API im Hystrix Dashboard aufzeichnen und auswerten.

hystrix-fedora

All diese Vorteile sind ohne eine einzige Anpassung des Fedora4 Systems möglich. Auf dieselbe Art  und Weise haben wir einen reinen Javascript Microservice eingebunden.

 

Fazit

Wie dieser Beitrag zeigt, ist die Integration einer Softwarekomponente, welche nicht den Netflix Stack via Bibliotheken Integration nutzen kann, sehr einfach. Die aufgezeigten Möglichkeiten, welche sich dadurch bieten finde ich beeindruckend. Hinzufügen muss ich allerdings, dass sich auf diese Art und Weise nur Softwarekomponenten integrieren lassen, welche über eine REST API angesprochen werden können. Da alle Aufrufe dieser REST API über Sidecar geroutet werden. Für Softwarekomponenten ohne REST API ist die Integration ebenfalls möglich aber etwas aufwendiger.

Microservices, Widerstandsfähigkeit

Widerstandfähigkeit eines Microservices Systems in Bezug auf Serviceausfälle oder Netzwerklatenz war ein wichtiger Aspekt, welchen wir in unserem Microservices Projekt eingehend untersuchen wollten. Daher freue ich mich dieses Thema und unsere Erfahrungen in unserer Blogserie etwas eingehender beleuchten zu können.

Widerstandsfähig bezieht sich hierbei auf die Client Anwendung, welche die einzelnen nachgelagerten Microservices verwendet. Dieser Begriff meint dabei, dass die Client Anwendung auch im Fall von Netzwerk- bzw. Serviceausfällen nicht blockiert und immer noch durch den Anwender verwendet werden kann. Blockieren kann die Anwendung zum Beispiel, wenn diese einen Microservice verwendet, welcher sehr viel Zeit benötigt, um eine Antwort im Netzwerk bereit zu stellen. Warum dieser Microservice nicht schnell genug antwortet, spielt bei dieser Betrachtung keine Rolle. Die Client Anwendung wartet solange bis entweder die Antwort eintrifft oder aber ein zuvor definierter Timeout einen Fehler erzeugt. Eine hohe Wartezeit einer Anfrage kann bei starker Verwendung der Client Anwendung dazu führen, dass immer mehr Anfragen der Nutzer das System immer stärker blockieren. Ein Blockieren der Client Anwendung kann aber auch durch eine Überlastung des Netzwerks ausgelöst werden. Die Client Anwendung fühlt sich in solchen Fällen für den Nutzer träge und langsam an. Im Falle von Webanwendungen verlässt der Nutzer in der Regel dann sehr schnell die Seite.

 

Als Lösung für solche Situationen bietet der Netflix OSS das Projekt Hystrix, als sogenannte „Circuit Breaker“ Bibliothek, an. Ein „Circuit Breaker“ ist eine Sicherung, welche ausgelöst wird, sobald gewisse Umstände eintreten. Hystrix bietet darüber hinaus viele zusätzliche Funktionalitäten:

 

  • kapselt ein Kommando und bietet synchrone und asynchrone Ausführung,
  • löst nach definiertem Timeout die Sicherung aus,
  • führt jedes Kommando in einem definierten Thread Pool aus,
  • auslösen der Sicherung bei zu hoher Fehlerrate eines Kommandos,
  • ermöglicht die Ausführung eines Fallbacks im Fehlerfall,
  • erzeugt Performance Metriken,
  • ermöglicht die Nutzung eines Caches.

 

Alle diese Funktionalitäten stehen zur Verfügung, sobald ein in der Client Anwendung ausgeführtes Kommando in ein “HystrixCommand” überführt wird. Meiner Meinung nach ist es wichtig, den nachfolgend abgebildeten Ablauf der Ausführung eines Hystrix Kommandos zu verstehen.

Abbildung .1: Netflix, Hystrix Command Fflow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Abbildung .1: Netflix, Hystrix Command Flow Chart, Web URL: https://github.com/Netflix/Hystrix/wiki/How-it-Works [Stand 2016-05-25]

Die detaillierte Beschreibung des Ablaufs finden Sie hier. Der Grund, warum ich diese Abbildung hier aufgeführt habe ist, dass diese sehr schön zeigt, dass Hystrix nicht nur ein reiner Ciruit Breaker ist. Wie zu erkennen ist, bietet Hystrix ein definiertes Verfahren zur Absicherung eines Netzwerkkommandos. Es besteht mit Hilfe der Hystrix Metriken die Möglichkeit sehr einfach und bequem Antwortzeiten auszuwerten. Durch die Integration konnten wir in unserem Projekt die Antwortzeiten eines Fedora4 Content Repository Servers, eines EMC S3 Object Storage Servers und des lokalen Dateisystems vergleichen. Die Hystrix Metriken konnten wir sehr einfach mittels des Hystrix Dashboards visualisieren und in Echtzeit auswerten. So kann auch in produktiven Umgebungen die Reaktions- bzw. Widerstandsfähigkeit einzelner Systeme optimal bewertet werden. Dies ersetzt natürlich keine umfassende Monitoringlösung, bietet aber die Möglichkeit, die Auslastung einzelner Systeme schnell zu erkennen und richtig zu behandeln.

 

Die Integration

Die Integration von Hystrix ist, wie auch bei den anderen “Platform Services” Komponenten, einmal mittels der nativen Netflix Bibliothek oder aber auch über das Spring Cloud Projekt möglich. In unserem Projekt haben wir beide Möglichkeiten erfolgreich durchgeführt.Spring Cloud bietet eine sehr einfache und leichte Integration via Annotation:

 

Beispiel:

@HystrixCommand(commandKey = “DMS->EMCS3:findObjectContent”, groupKey = “DMS->EMCS3”)

 

Hierbei wird lediglich der Name des Kommandos und des Threadpools definiert. Es ist über die Zusatzbibliothek hystrix-javanica zusätzlich möglich, alle Konfigurationswerte direkt in der Annotation aufzuführen. Wir haben uns allerdings dazu entschieden, die Konfiguration in der zentralen „application.properties“ Datei durchzuführen.

 

Im Bereich der nativen Netflix Bibliothek ist die Integration ebenfalls sehr leicht. Nach dem Einbinden der Abhängigkeiten hystrix-core und hystrix-metrics-event-stream kann die Integration durchgeführt werden. Die Klasse, mit welcher ein Kommando im Netzwerk ausgeführt wird, muss lediglich die Klasse HystrixCommand erweitern und die Methode run() implementieren. Die Konfiguration erfolgt über die Datei “eureka-client.properties”.

Bei einigen Standardwerten der Konfiguration mussten wir Anpassungen vornehmen, da Hystrix die Sicherung für unseren Anwendungsfall zu schnell ausgelöst hat. Dies ist uns bei Belastungstests mit dem Werkzeug JMeter aufgefallen. Letztendlich konnten wir mit folgenden Einstellungen ein sehr gutes Antwortverhalten bei einer stark belasteten Komponente erzeugen:

 

hystrix.command.default.execution.isolation.strategy=THREAD

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=120000

hystrix.command.default.execution.isolation.thread.maxConcurrentRequests=1024

hystrix.command.default.fallback.isolation.thread.maxConcurrentRequests=1024

hystrix.threadpool.default.coreSize=1024

hystrix.threadpool.default.maxQueueSize=1024

hystrix.threadpool.default.keepAliveTimeMinutes=2

hystrix.threadpool.default.queueSizeRejectionThreshold=15

hystrix.threadpool.default.metrics.rollingStats.numBuckets=12

hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds=1440  

 

Sich diese Konfigurationswerte genau zu betrachten und diese festzulegen, ist ein wichtiger Schritt bei der Integration von Hystrix. Allerdings muss natürlich jeder selbst entscheiden, welche Werte für welches Kommando sinnvoll sind.

 

Fazit

Die Integration ist, wie bereits bei den anderen “Platform Services” des Netflix OSS, nicht sehr aufwendig. Dieses Werkzeug, finde ich persönlich, wegen der vielen zusätzlichen Funktionalitäten sehr interessant und nützlich. Es bietet eine standardisierte Lösung, um ein Netzwerkkommando gesichert auszuführen, ein Fallback zur Verfügung zu stellen, einen Cache zu nutzen und Performancemesswerte zu erzeugen. In Zukunft werde ich für mich persönlich daher immer bewerten, ob nicht die Verwendung dieser Bibliothek bei jeglichen Netzwerkzugriffen eines Projektes sinnvoll ist.

Microservices, Load Balancing

Die Prüfung der Skalierbarkeit von Microservices war ein weiteres sehr wichtiges Thema in unserem Microservices Projekt. Im Rahmen unser dazugehörigen Blog Serie möchte ich hier das Thema Load Balancing im Kontext der Microservice Architektur näher beleuchten. Häufig werden im Bereich der Bibliothekssysteme zentrale Dienste, wie zum Beispiel ein zentrales Dokumentenmanagement wie Fedora oder eine zentrale Suche mit Solr oder Elasticsearch benötigt. In unserem Projekt wollten wir herausfinden, wie und mit welchem Aufwand Services dynamisch skaliert werden können. Dies bedeutet, dass in Situationen in welchen die Client Anwendungen durch die Nutzer der Bibliothek stark verwendet werden, die Services dynamisch auf zusätzliche Server installiert und anschließend verwendet werden. Dynamisch bedeutet an dieser Stelle automatisiert und damit ohne Administrations-, Konfigurations- bzw. Entwicklungsaufwand.

Wie in unserem ersten Beitrag beschrieben, bietet die Microservices Architektur unter anderem den Vorteil der einfacheren und genaueren Skalierung einzelner Microservices. Wird nun eine Softwarekomponente bzw. ein Service auf mehrere Server automatisiert installiert, müssen diese auch durch die Anwendungen genutzt werden können. Als Teil der „Platform Services“ bietet der Netflix Open Source Stack (Netflix OSS) auch hier eine sehr gute Lösung. Bevor ich die konkrete Lösung vorstelle, möchte ich noch etwas zur Theorie des Load Balancing sagen. Grundsätzlich gibt es zwei wesentliche Varianten um dieses aufzubauen.

 

Zentrales Load Balancing.

Dabei wird ein zentraler Load Balancer zwischen den Client Anwendungen und den Services aufgebaut. Alle Anfragen der Clients werden über den Load Balancer geroutet und dieser verteilt die Anfragen nach einem bestimmten Verfahren auf die einzelnen Service Instanzen. Ein Nachteil dieser Lösung ist, dass der Load Balancer ein Single Point of Failure ist. Dies bedeutet, dass wenn diese Komponente ausfällt bzw. stark überlastet ist, sie keine Anfragen mehr von den Anwendungen zu den Services weiterleitet.

Zentrales Load Balancing

Zentrales Load Balancing

Dezentrales Load Balancing

Hierbei hält die Client Anwendung alle Informationen, welche Service Instanzen verfügbar sind, bei sich lokal vor. Diese Informationen werden regelmäßig aktualisiert, sodass die aktuelle Situation der verfügbaren Services dem Client jederzeit bekannt ist. Die Client Anwendung entscheidet mit Hilfe eines eingebauten Load Balancing Mechanismus selbst, welche Service Instanz für eine Anfrage verwendet wird. Damit ist keine zentrale Load Balancer Instanz mehr notwendig und es gibt keinen Single Point of Failure. Auch bei dieser Lösung gibt es wiederum Nachteile, dass zum Beispiel die lokale Information, welche Instanzen der Services verfügbar sind, veraltet sein kann.

Dezentrales Load Balancing

Dezentrales Load Balancing

Die einzelnen Load Balancing Verfahren, nach welchem Algorithmus eine von mehreren verfügbaren Service Instanzen ausgewählt wird, möchte ich hier nicht aufführen, da es in diesem Beitrag um die Integration im Bereich der Microservices Architektur geht und nicht um das Load Balancing als solches. Der Netflix OSS bietet mit der Bibliothek Ribbon eine Möglichkeit des dezentralen, client-seitigem Load Balancing. Die Information, welche Service Instanzen auf welchem Server verfügbar sind, basieren auf den Informationen aus der Service Registry Eureka. Durch die Integration von Eureka ist das Load Balancing dynamisch und wird jederzeit an die verfügbaren Instanzen angepasst. Es ist auch möglich, Ribbon ohne Eureka einzusetzen, was hier aber nicht näher erläutert werden soll, da es für den produktiven Einsatz nicht empfohlen werden kann.

 

Unsere Erfahrungen

Die Integration von Ribbon in eine Client Anwendung ist einmal mit der Spring Cloud oder aber durch die Einbindung der nativen Netflix Bibliothek möglich. Bei beiden Varianten gibt es jeweils die Möglichkeit mittels direkter Verwendung eines Ribbon Clients das Load Balancing zu integrieren oder die Methode REST Templates zu definieren und zu verwenden. Beide Varianten unterscheiden sich vom Aufwand nicht. Elegant bei der Template Variante ist aus meiner Sicht die Trennung der Definition der zur Verfügung stehenden Funktionalität und deren Verwendung. So können zentral alle zur Verfügung stehenden Templates definiert und diese anschließend an den unterschiedlichsten Stellen eingesetzt werden. Dies vereinfacht die Wartung der bestehenden Möglichkeiten sehr stark. Allerdings konnten wir beim Einsatz des REST Templates für einen HTTP POST Request mit Multipart Upload nicht erfolgreich umsetzen. Beim Absetzen des HTTP POST Request wurde jeweils folgender Fehler gemeldet:

the request was rejected because no multipart boundary was found

Bisher haben wir noch keine Antwort zu unsere Anfrage nach einer Lösung aus der ribbon usergroup erhalten. Zusätzlich zur Integration im Quellcode muss das Load Balancing noch konfiguriert werden. Hier kann zum Beispiel auch zwischen den möglichen Verteilungsverfahren gewählt werden. Ribbon unterstützt zum Beispiel folgende:

  • RoundRobinRule
  • AvailabilityFilteringRule
  • WeightedResponseTimeRule

Alle Details zur Konfiguration von Ribbon können im Wiki des Projektes nachgelesen werden. Zusammenfassend können wir sagen, dass die Integration von Ribbon in eine Anwendung ohne großen Aufwand umzusetzen ist und sehr zuverlässig funktioniert. Bis auf die Ausnahme des HTTP POST Multipart Request sind wir auf keine weiteren Schwierigkeiten gestoßen.

 

Einsatz des Load Balancing

Unsere Client Anwendungen im Pilotprojekt bietet die Funktion eines Upload von XML Dateien. Diese lädt die Dateien nach der Auswahl im Browser via einer REST Schnittstelle in ein Dokumentenmanagementsystem (Microservice). In die Client Anwendungen haben wir das Load Balancing mit Hilfe der nativen Netflix Bibliothek integriert. In einem Test eines Ausfalls von einem der Dokumentenmanagement Services während des Uploads von 1000 XML Dateien konnten wir zeigen, dass der Upload nicht beeinträchtigt wird. Der Anwender bemerkt nicht, dass zu Beginn des Uploads noch zwei und während des Uploads nur noch eine Service Instanz des Dokumentenmanagement Services die Daten speichert. Ohne den Einsatz von Eureka und Ribbon wäre der Upload bei Ausfall des Dokumentenmanagement Services abgebrochen.

 

Fazit:

Auch für das Thema Load Balancing kann ich den Einsatz für zentrale Services in Kombination mit einer Service Registry nur stark empfehlen. Der Aufwand der Integration in eine Java Anwendung ist meines Erachtens eher gering und lohnt sich. Nach Abschluss der Integration können die Microservices einfach skaliert und die Client Anwendung kann so jederzeit stärker verwendet werden und reagiert robuster auf Ausfälle.

Microservices, Service Registry „Die Zentrale“

Im Rahmen unseres IT Projektes “Microservices” und der damit verbundenen Blog Serie möchte ich in diesem Beitrag über unserer Erfahrungen mit den „Platform Services“, welche ein zentraler Baustein in der Microservices Architektur sind, berichten. Es sind zusätzliche Dienste welche den Betrieb von zahlreichen Anwendungsservices vereinfachen. Dazu gehören unter anderem

Alle diese Dienste ermöglichen es eine große Anzahl an Microservices zu betreiben und nutzbar zu machen. Diese Auflistung sieht auf den ersten Blick nach sehr viel Aufwand und technischer Infrastruktur aus und beinhaltet Begrifflichkeiten, welche tiefgehendes, technisches Wissen erfordern um die Bedeutung und Notwendigkeit verstehen zu können. Aus diesem Grund möchte ich in den kommenden drei Beiträgen etwas Licht ins Dunkle bringen und versuchen den Mehrwert dieser technischen Services zu erläutern. Beginnen möchte ich mit der Service Registry, weil diese aus meiner Sicht die grundlegendste Komponente ist auf welcher viele der anderen Services aufsetzen.

 

Die Services Registry stellt in gewisser Weise eine Art Telefonzentrale dar , die Clientanwendung, wie zum Beispiel ein Content Management System oder aber eine andere beliebige Webanwendung, anrufen können um nach einem Dienst zufragen, welcher gerade benötigt wird. Tatsächlich fragt die aufrufende Anwendung mit einem Namen wie zum Beispiel: “Suche” oder “Dokumentenmanagement” die Service Registry und erhält die Information wie dieser Service zu erreichen ist. Die Information beinhaltet eine vollständige URL und kann als Einstiegspunkt zur Verwendung des Service benutzt werden.

 

Die einfachere und klassische Variante ohne die Verwendung einer Service Registry ist, dass die Client Anwendung die URL auf den Einstiegspunkt selber gespeichert hat. Allerdings gibt es bei dieser klassischen Variante einige Nachteile:

 

  • Die URL ist statisch in der Clientanwendung gepflegt und muss bei Veränderungen der URL mit geändert werden. Zieht der zu nutzende Service auf einen anderen Server um oder ändert sich der TCP/IP Port, muss die Clientanwendung in der Regel mit angepasst werden.
  • Es ist keine Verwendung von clientseitigem Load Balancing möglich. Das bedeutet, selbst wenn der Service auf mehreren Servern eingerichtet ist, kann der Client diese nicht dynamisch nutzen.
  • Es gibt oft keine Echtzeit Übersicht über den aktuellen Stand der zur Verfügung stehenden Services. Es besteht natürlich die Möglichkeit, ein sehr gutes Monitoring einzurichten, was diese Fähigkeit besitzt. Allerdings sind die klassischen Monitoring Lösungen wie zum Beispiel Nagios dafür nicht konzipiert und vorgesehen. In den meisten Fällen sind diese auch so nicht eingerichtet.

 

Diese aufgeführten Nachteile der herkömmlichen Verknüpfung von Clientanwendung und Anwendungsdienst (Service)  zeigen im Umkehrschluss natürlich auch die Vorteile einer Service Registry:

 

  • Zentrale Übersicht aller Service und deren Status
  • Möglichkeit eines Load balancing
  • Keine clientseitige Anpassung bei Service und Infrastruktur Änderungen

 

Aber rechtfertigen diese Vorteile den Aufwand und den Betrieb einer Service Registry? Der Aufwand der Installation einer Service Registry ist sehr gering, da es bereits sehr gute und ausgereifte Produkte gibt:

 

 

Die beiden erst genannten Produkte sind diejenigen mit der höchsten Verbreitung und damit auch die ausgereiftesten. In unserem Projekt haben wir hauptsächlich auf den Netflix OSS gesetzt und daher auf Eureka. Auch wir haben in unserem Pilotprojekt sehr gute Erfahrungen mit Eureka gemacht. Wichtig bei der Verwendung ist, dass die Service Registry nicht wiederum selbst zum Single Point of Failure wird und daher immer mehrfach betrieben werden sollte. Aber auch dieser Aspekt ist mit sehr geringem Aufwand umzusetzen. Ich empfehle für den Einstieg daher ein Spring Boot Projekt mit aktivierter Service Registry, welches im Beispiel Microservices Projekt von Eberhardt Wolff zur Verfügung steht. Sie werden erstaunt sein, mit wie wenig Quellcode die Service Registry umgesetzt ist.

Der Quellcode…

@SpringBootApplication
@EnableEurekaServer
@EnableDiscoveryClient
public class ServiceRegistryApplication {

public static void main(String[] args) {
SpringApplication.run(ServiceRegistryApplication.class, args);
}
}

 

Fazit:

Aus meiner persönlichen Sicht ist der Einsatz einer Service Registry auch ohne die Verwendung der gesamten Microservices Architektur von unschätzbarem Vorteil, sobald mehrere zentrale Services im Hause betrieben werden. Alleine die Tatsache, dass nicht mehr mit jeder Infrastruktur Anpassung die Client Anwendung und die Dokumentation bzw. das Monitoring angepasst werden müssen, sind im Dauerbetrieb mit geringem Personaleinsatz von unschätzbarem Wert. Hinzu kommt, dass wir in unserem Beispiel Projekt sowohl die Anbindung von Java Webanwendungen als auch von reinen HTML / Javascript Anwendungen relativ einfach umsetzen konnten. Wir konnten aus dem weit verbreiteten CMS Typo3 sehr leicht die Service Registry nach einem Service anfragen und diesen anschließend nutzen. Integriert man diese Anfrage Logik zum Beispiel in eine Typo3 Extension und macht diese so nachnutzbar für andere Typo3-Projekte, wird der Aufwand auf alle Projekte betrachtet noch geringer und der Nutzen somit noch größer. Zusätzlich bietet eine Service Registry als Basis der Platform Services weitere Möglichkeiten, welche ebenfalls von unschätzbarem Wert, um stabilen Betrieb von zentralen Services sind.

 

Diese Möglichkeiten werde ich in den kommenden Beiträgen detailliert aufführen und zeigen, wie man zum Beispiel ein bestehendes Fremdsystem, wie zum Beispiel Fedora Content Repository oder Pazpar2-Suche, in eine solche Service-Struktur einfach einbindet, ohne die Produkte selbst anpassen zu müssen.

Ich freue mich daher auf die kommenden Beiträge und hoffe auf zahlreiche Kommentare.

Microservice-Projektblog: Eierlegende Wollmilchsau

In der Abteilung Informations- und Datenmanagement der Staatsbibliothek zu Berlin (IDM) wird derzeit evaluiert, inwieweit das Architekturmuster„Microservices“ als Grundlage zukünftiger Eigenentwicklungen hilfreich sein können. In einer Reihe von Blogbeiträgen geben wir im Sinne eines Werkstattberichtes einen Einblick in das Projekt und unsere Erfahrungen mit der Umsetzung.

Der Auslöser unserer Neugier auf die relativ neue Technologie war die konkrete Aufgabe, dass ein Altsystem im Bereich der Nachweissysteme (Gesamtkatalog der Wiegendrucke) technisch modernisiert werden sollte. Soweit kein ungewöhnlicher Fall: in gewohnter Arbeitsweise wurde ein Team aus Entwicklern und einem fachliche Experten zusammengestellt. Eine Kleinigkeit war allerdings diesmal anders. Es gab neben den fachlichen Anforderungen – die Modernisierung des Nachweissystems zum Gesamtkatalog der Wiegendrucke – auch folgende nicht funktionalen Anforderungen:

  • Leichte Erweiterbarkeit des Systems
  • Testbarkeit
  • Hoher Grad an Wiederverwendungsmöglichkeiten
  • Skalierbarkeit

Mein erster Gedanke war: aha wir sollen also die „eierlegende Wollmilchsau“ entwickeln.

Der offensichtliche Grund für diese neuen Anforderungen war, dass in den letzten Jahren an der Staatsbibliothek im Rahmen von Projekten zwar funktional sehr gute Softwaresysteme entstanden sind, diese allerdings nicht in jedem Fall optimal betrieben, gewartet und nachgenutzt werden konnten. Zudem wiederholten sich zunehmend ähnliche fachliche Anforderungen nach Suche in Metadaten, Authentifizierung, Erfassung und Verwaltung der Metadaten sowie Präsentation der Metadaten. Diese nicht funktionalen Anforderungen führten zur Suche nach neuen Architekturansätzen für Enterprise Software. Microservices versprechen auf den ersten Blick viele der Anforderungen zu erfüllen, nun sind aber die bekannten Fragen zu klären:

  • Wie definieren sich Microservices?
  • Wann sollte die Microservices Architektur verwendet werden?
  • Wie entwickle ich konkret Microservices?
  • Wie betreibe ich Microservices?
  • Erreiche ich mit Microservices die nicht funktionalen Anforderungen besser?

Alle diese Fragen waren auch nach der Lektüre etlicher Fachaufsätze und Publikationen für uns nicht eindeutig genug zu beantworten. Im Großen und Ganzen liegt es an der Komplexität und Umfang der Gesamtarchitektur der IT Systeme der Staatsbibliothek und dem auch aus Informatikersicht anspruchsvollen Thema Microservices. Es gibt bei der Staatsbibliothek nicht den klassischen Fall eines bestehenden, monolithischen Systems welches mit der Microservice Architektur ersetzt oder ergänzt werden soll. Es gibt auch nicht die *eine* Webpräsentation, auf welche alle Usecases und Fachlichkeiten dargestellt und realisiert werden. Anstelle dessen gibt es sehr viele heterogene Anwendungssysteme auf einer gemeinsamen Infrastruktur.

Um nun genau zu evaluieren, ob und in welchem Umfang Microservices einige Dinge innerhalb der IT Landschaft der Staatsbibliothek verbessern können, und diese wirklich als ganzheitliches Integrationskonzept gesehen werden kann, sollen diese Fragestellungen nun in einem eigenständigen Projekt geklärt werden.

Im Rahmen dieses Projektes werden ich und meine Kollegen dieses Blog regelmäßig mit Informationen zum Thema Microservices und unseren Erfahrungen dazu ergänzen. Unsere Ziele sind:

  • Einen noch höheren Grad der fachlichen Nachnutzung einzelner Services
  • Eine einheitliche Integrationsstrategie
  • Eine Infrastrukturplattform die Microservices bzw. die fachlichen Anwendungen ausfallsicherer, höher verfügbar, skalierbarer und flexibler macht
  • Schnellere Realisierung von fachlichen Anforderungen

Ein guter Einstieg in das Thema Microservices ist dieser Beitrag von Martin Fowler. Hier werden die grundlegenden Fragestellungen erörtert sowie auf viele weitere Informationsquellen verwiesen.

Ebenfalls empfehle ich das Buch zum Thema Microservices mit dem Titel „Microservices: Grundlagen der flexiblen Softwarearchitektur“ von Eberhard Wolff.

Natürlich freuen wir uns auf Kommentare, sollten Sie in Ihren Einrichtungen bereits Erfahrungen mit Konzeption und dem Einsatz von Microservices gesammelt haben.