Beiträge zu Innovationen in unserem IT-Bereich

Slavistik-Portal im neuen Design online

Seit Anfang Januar 2017 präsentiert sich das Slavistik-Portal im neuen, responsiven Design, das vor allem für die Recherche mit mobilen Geräten und Browsern aller Art optimiert ist. Gleichzeitig wurde das Portal auch für die Arbeit mit herkömmlichen Desktop-PCs verbessert und übersichtlicher gestaltet.

Das Slavistik-Portal ist aus dem Projekt „Virtuelle Fachbibliothek Slavistik“ hervorgegangen, das ab 2005 für fünf Jahre von der Deutschen Forschungsgemeinschaft gefördert wurde. Das Ziel der Virtuellen Fachbibliothek (ViFa) Slavistik war definiert als Schaffung einer zentralen Anlaufstelle für slavistikbezogene Fachinformationsangebote im Internet. Die ViFa Slavistik richtete sich primär an Wissenschaftler und Studierende, aber auch an Lehrer, Übersetzer, Journalisten, Kulturmanager und alle diejenigen, die an Slavistik, slawischen Sprachen und Literaturen sowie slawischer Volkskunde interessiert waren.

Die Grundlage der „ViFa“ Slavistik bildete das Sondersammelgebiet (SSG) „Slawische Sprachen und Literaturen“, das von 1998 bis 2015 an der Staatsbibliothek zu Berlin gepflegt wurde und die deutschen SlawistInnen mit slawistischer Fachliteratur in diesem Zeitraum erfolgreich versorgt hatte. Seit 2016 betreut die Staatsbibliothek zu Berlin nun den Fachinformationsdienst (FID) Slawistik, der im Gegensatz zum SSG weit über die bloße Versorgung der FachwissenschaftlerInnen mit Fachliteratur hinausgeht. Das Slavistik-Portal, das nach wie vor – mit über 5000 Besuchern pro Monat vor allem aus dem deutschsprachigen Raum – als die zentrale Anlaufstelle für Fachrecherchen fungiert, wird auch in den kommenden Jahren und im Rahmen des FID seine Dienste anbieten, die Services erweitern und weiterhin die deutsche und internationale FachnutzerInnen mit relevanten wissenschaftlichen Fachinformationen versorgen.

Die Hauptmodule des Portals und ihre technische Basis verfolgen das Ziel, den Nutzern eine übersichtliche und transparente Webpräsentation zu bieten, die gutes Design und Performanz verbindet und die auf fachlichem Know-how und zwölf Jahren intensiver Arbeit an den Inhalten und der technischen Infrastruktur aufbaut.

  • Suche – Die Funktion „Suche in slawistischen Datenbanken, Bibliographien und Katalogen“ deckt einen Suchraum von über 40 Datenquellen ab, die fachbezogenen Informationen zur und über die Slawistik liefern. Als Software kommt dabei seit 2013 das Open-Source-System Pazpar2 zum Einsatz, das in der Lage ist, die lokalen bibliographischen Daten, die in Form von SOLR-Indizes vor Ort in Berlin vorgehalten werden, aber auch die entfernten Fachquellen über diverse XML- oder Z39.50-Schnittstellen, in Sekundenschnelle zu durchsuchen. Die ca. 30 lokalen SOLR-Indizes sind mit speziellen Analyzern (mit Funktionen wie automatischer Transliteration des Kyrillischen o.a.) ausgestattet, so dass die Suche darüber sich für Slavistik-SpezialistInnen besonders effektiv gestaltet. Eine vorsichtige Schätzung der fachbezogenen Datensätze im gesamten Suchraum liegt ca. 5 bis 10 Mio. bibliographischen Einheiten.
  • Neuerwerbungen – Unter „Neuerwerbungen“ bietet das Portal den Dienst „Neuerwerbungen Slavistik“, der die monographische Erwerbung für den gesamten deutschsprachigen Raum (im Auftrag der Deutschen Forschungsgemeinschaft) der letzten 15 Jahre widerspiegelt, und den kürzlich hinzugekommenen Dienst „Neuerscheinungen Online Content (OLC) Slavistik“, der die Zugänge aus den 500 wichtigsten slavistischen Zeitschriften auf der Aufsatzebene dokumentiert. Beide Dienste sind datenbankbasiert und werden im Stundentakt aktualisiert. Dementsprechend können sie auch als RSS-Dienste genutzt werden.
  • Zeitschriften – Das Modul bietet eine Übersicht über die wichtigsten gedruckten und elektronischen Zeitschriften im Fachbereich Slawistik. Die Daten aus der „Elektronischen Zeitschriftendatenbank“ (EZB) und der „Zeitschriftendatenbank“ (ZDB) werden über die XML-Schnittstellen ausgelesen und sind somit immer aktuell. Eine Ergänzung liefert die Übersichtsliste über die Zeitschriften in der Datenbank „Online Contents (OLC) Slavistik“, die ebenfalls stets „up to date“ ist.
  • Datenbanken – Dieses Modul bildet das Herzstück des Portals. Auf über 300.000 Webseiten werden die bibliographischen Metadaten für die wichtigsten deutschsprachigen slavistischen Bibliographien und die fachbezogenen Regionalbibliographien angeboten. Die Metadaten davon wurden durch die Konversionsprojekte der Jahre 2007-2012 aus den gedruckten Ausgaben durch spezialisiertes OCR gewonnen und mit Data-Mining-Verfahren strukturiert. Nun liegen die ehemals gedruckten Bibliographien in Datenbankform vor und werden für die Browsing-, Pazpar2- und die Widget-Suche in die SOLR-Indizes eingespeist. Ergänzend zu den Bibliographien bietet das Modul auch eine Auswahl von ca. 2000 Internetquellen, die das Team des Portals im Laufe der letzten zehn Jahre gesammelt hatte und die – aus unserer Sicht – für die deutsche und internationale Slawistik von Bedeutung sein dürften.
  • Online-Tutorium – Das Online-Tutorium LOTSE-Slavistik (als ein Teilprojekt der „ViFa“ Slavistik) war als Lernportal gedacht, das Suchtechniken im Fach Slavistik vermitteln sollte. Es wurde fünf Jahre lang von der Universitätsbibliothek Bochum gepflegt und anschließend von der SUB Hamburg eine Zeitlang gehostet. Zum Ende 2016 wurde das gesamte LOTSE-Projekt eingestellt.

Nach wie vor wird am Slavistik-Portal intensiv gearbeitet. Vor allem die Gewinnung neuer, qualitativ hochwertiger Metadaten wird vorangetrieben. Es werden weitere gedruckte Bibliographien im Data-Mining-Verfahren erschlossen und weitere elektronischen OAI-Server des Fachbereichs weltweit geharvestet. Auch der Zugang zu freien und lizenzpflichtigen Volltext-Quellen/-Datenbanken spielt zunehmend eine wichtige Rolle. So wird seit Herbst 2016 eine deutschlandweite FID-Lizenz für die Volltext-Datenbank „Universitetskaja biblioteka online“ über das Slavistik-Portal angeboten, die registrierten Nutzern zur Verfügung steht.

Auch in Zukunft werden wir den Grundsätzen der Transparenz und Performanz eine besondere Bedeutung beimessen und unser Portal danach gestalten. Die jüngste Entwicklung betrifft das neue, responsive Design des Portals, das seit Januar 2017 online ist. Damit haben wir unsere Webseiten auch für diejenigen Nutzer und Nutzerinnen optimiert, die mit mobilen Geräten und Browsern aller Art zu uns kommen wollen.

Herzlich willkommen! Zur Suche: http://slavistik-portal.de

Drucken leicht(er) gemacht

Wir freuen uns, Ihnen in Zusammenarbeit mit unserem Druck- und Reproduktionspartner BiblioCopy einen neuen Service präsentieren zu können: Den WLAN-Druck.

Dazu ein Beispiel aus der Praxis: Sie arbeiten gerade konzentriert an Ihrem Laptop im Lesesaal und stoßen bei Ihren Recherchen auf einen äußerst interessanten Zeitschriftenaufsatz, den Sie gerne sofort ausdrucken möchten. Bisher war der Weg häufig so: Zunächst haben Sie sich den Aufsatz heruntergeladen und auf einem USB-Stick gespeichert, um diesen anschließend bei BiblioCopy wieder an einen Drucker oder PC anzuschließen und das Dokument auszudrucken.

Das geht ab sofort einfacher, denn jetzt können Sie direkt über das WLAN der Staatsbibliothek den Drucker im Kopierzentrum BiblioCopy ansteuern und Ihren Druckauftrag in Arbeit geben. Um den Drucker bei BiblioCopy ansteuern zu können, bedarf es lediglich der Verbindung mit dem WLAN der Staatsbibliothek und der einmaligen Installation des Druckers. Die Anleitung zur Installation des Druckers und alle wichtigen Informationen finden Sie auf der Seite von BiblioCopy.

Uns ist bewusst, dass die Installation (im Vergleich zum heimischen Drucker) recht aufwendig ist, aber dafür gibt es auch einen sehr guten Grund: die Sicherheit Ihrer Daten. Wir müssen zu jeder Zeit sicherstellen können, dass der Druckauftrag auch wirklich von Ihnen gewünscht war und wir den Druckauftrag Ihnen (und niemand anders) zuordnen können, damit Sie am Ende auch wirklich das Gewünschte in den Händen halten. Wir bitten daher um Ihr Verständnis.

In der ersten Phase steht der WLAN-Druck allen Nutzerinnen und Nutzern mit Laptops der Betriebssysteme Windows 7 und 10 zur Verfügung. An einer Lösung für weitere Betriebssysteme wird intensiv gearbeitet. Bis dahin können Sie die Funktion des Ausdrucks per Upload nutzen.

Sollten Sie Fragen zur Installation haben oder Hilfe benötigen, können Sie sich gerne an die WLAN-Sprechstunde wenden.

Übrigens: Wir erfüllen mit dem WLAN-Druck einen von Ihnen bei der WLAN-Umfrage im März häufig geäußerten Wunsch. Ihre Anregungen und Kritiken bleiben also keineswegs ungehört.

Grüne Welle für Ihre Recherchen – stabikat+ mit Verfügbarkeitsampel

Auch in unserer Literatursuchmaschine stabikat+ erkennen Sie die Verfügbarkeit eines Buches aus unserem Bestand – in Echtzeit – jetzt schon in der Trefferliste. Die Einstellungen der Verfügbarkeitsanzeige im klassischen Katalog und in stabikat+ sind selbstverständlich identisch. Die Ampelfarben sowie die zugehörigen Ausschriften beschreiben jeweils den aktuellen Status des gesuchten Mediums.

Unsere Ampelfarben – wie im klassischen StaBiKat

Grün steht für aktuell verfügbare, bestellbare Bände und Präsenzbestand in den Lesesälen sowie für online verfügbare Quellen.
Gelb angezeigt werden verliehene, vormerkbare Bände aber auch noch einige ältere Werke mit dem Hinweis Kriegsverlust möglich, an deren Datenkorrektur wir fortlaufend arbeiten.
Rot werden Werke gekennzeichnet, die nicht mehr in der Staatsbibliothek vorhanden oder langfristig nicht zugänglich sind, also Verluste oder vermisste Bände, die aber der Vollständigkeit halber weiterhin im Katalog angezeigt bleiben.
Graue Buttons sehen Sie, wenn zu einem Treffer mehrere Exemplare oder mehrere Bände gehören. Die Ampelfarben finden Sie dann erst nach dem Klick auf den Titel der Publikation in der Detailanzeige des Treffers wieder.
Der farbige Button mit der zugehörigen Ausschrift führt entweder direkt zum Bestellen oder zur Detailanzeige im klassischen StaBiKat.

Volltexte online in stabikat+

Bei Dokumenten ohne farbige Buttons gelangen Sie auf unterschiedlichen Wegen zu den gefundenen Ergebnissen.

  • Bei einem Dokument mit PDF-Symbol können Sie direkt auf den gesuchten Text zugreifen.
  • link@sbb ergänzt durch die Ausschrift Zum Volltext führt Sie über einen Linkresolver direkt zum elektronischen Volltext des gesuchten Aufsatzes.
  • link@sbb in Kombination mit der Ausschrift Verfügbarkeit prüfen führt Sie über den Linkresolver zum Eintrag der Zeitschrift im klassischen StaBiKat und hier entweder zur elektronischen Version mit Zugriffslink oder zur Druckausgabe der Zeitschrift mit Bestellmöglichkeit des gesuchten Bandes.
  • Ein Link mit dem Wortlaut „View record from …“ gibt Ihnen einen Hinweis auf einen Text aus einem Open Access Repository (z.B. über die Suchmaschine BASE) oder einer bibliographischen Datenbank und Sie können über den Link in der Detailanzeige feststellen, ob der gefundene Treffer im Volltext zugänglich ist.

Nutzen Sie stabikat+ außerhalb der Lesesäle der Staatsbibliothek, finden Sie praktische Zugangsinformationen unter stabikat+ im Remote Access .

Fragen Sie uns!

In allen Zweifelsfällen bei der Zugänglichkeit der Dokumente sowie bei Ihren speziellen Rechercheanliegen oder anderen Belangen der Bibliotheksbenutzung unterstützen wir Sie selbstverständlich gern. Fragen Sie uns einfach!

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.

„Nachhaltigkeit und Zugang“ – Reinhard Altenhöner moderiert die Podiumsdiskussion

Die Digitalisierung des kulturellen Erbes hat in den letzten Jahren große Fortschritte gemacht. Doch angesichts der rasanten technologischen Entwicklung der elektronischen Medien, der Projektorientierung von Kulturförderung und der Flüchtigkeit digitaler Kommunikation gewinnen Fragen nach der Nachhaltigkeit an Bedeutung. Auf der 6. internationalen „Zugang gestalten!“-Konferenz sollen am 17. und 18. November 2016 die damit zusammenhängenden Aspekte erörtert werden.

Veranstaltungsort:
Hamburger Bahnhof – Museum für Gegenwart
Invalidenstr. 50-51
10557 Berlin

Der Eintritt ist frei – Tagungsprogramm

Innerhalb der Konferenz moderiert Reinhard Altenhöner, Ständiger Vertreter der Generaldirektorin der Staatsbibliothek zu Berlin – Preußischer Kulturbesitz und Leiter der Zentralabteilung der Staatsbibliothek, am 17. November eine Podiumsdiskussion zum Thema

Nachhaltigkeit und Zugang

Wenn die Verantwortung für das kulturelle Erbe eine gesellschaftliche ist, wer trägt sie dann genau und wie?

Das Panel “Nachhaltigkeit und Zugang” ist ideal besetzt, um zu diskutieren, welche Rollen Institutionen und Bürger heute haben und in Zukunft haben sollten, wenn es um die Nachhaltigkeit des Zugangs zum kulturellen Erbe geht. Hier stellen sich weniger Fragen des Eigentums an Kulturobjekten, sondern der Berechtigung, den Zugang zu ihnen zu regeln. Gedächtnisinstitutionen bewegen sich hierbei in einem Spannungsfeld zwischen spürbarem Veränderungsdruck auf ihr Selbstverständnis auf der einen und öffentlichem Auftrag auf der anderen Seite. Dadurch entsteht die Notwendigkeit zu strategischen Weichenstellungen, die in ihrer Tragweite noch vor wenigen Jahren kaum vorhersehbar waren.

 

 

10. November: Reinhard Altenhöner spricht über „Die Staatsbibliothek als digitale Bibliothek: Aktivitäten und Perspektiven“

Sehr geehrte Damen und Herren, liebe Kolleginnen und Kollegen,
wir möchten Sie herzlich zu folgender Veranstaltung des „BAK Information“ einladen:

Reinhard Altenhöner

spricht zum Thema

Die Staatsbibliothek als digitale Bibliothek: Aktivitäten und Perspektiven“

 

Das traditionell geprägte Bibliothekswesen ist durch die „Digitale Transformation“ stark in Bewegung geraten. Eine Herausforderung liegt darin, neue und agile Geschäftsmodelle auf Institutionen zu übertragen, die aufgrund der eigenen Geschichte in der Vermittlung von analogen Medien verankert sind, deren Benutzerinnen und Benutzer aber verstärkt in digitalen Kontexten agieren und dies selbstverständlich auch in eine Serviceerwartung gegenüber den Bibliotheken übertragen.

Aus dem Anspruch heraus, die „Kundschaft“ dort abzuholen, wo sie steht, möchte die Staatsbibliothek, ihre Aktivitäten im Bereich der digitalen Bibliothek deutlich erweitern. Dies beinhaltet sowohl, dass Servicebereiche weiter ausgebaut werden, denen digitale Infrastrukturen zugrunde liegen, als auch neue Tätigkeitsfelder mit Zukunftspotential zu besetzen.

Reinhard Altenhöner wird in diesem Vortrag aufzeigen, wo die SBB-PK hier Erfahrungen hat, wo die zukünftigen digitalen Betätigungsfelder liegen und welcher Organisationstrukturen sich die Bibliothek bedient, um diese zu erschließen.

Reinhard Altenhöner ist seit 2015 Ständiger Vertreter der Generaldirektorin der Staatsbibliothek zu Berlin – Preußischer Kulturbesitz und Leiter der dortigen Zentralabteilung. Zuvor war er 12 Jahre an der Deutschen Nationalbibliothek in Frankfurt/Main Leiter der Abteilung Informationstechnik und ab 2014 Fachbereichsleiter der Abteilung Informationsinfrastruktur und Bestandserhaltung.

Vortrag und Diskussion finden am Donnerstag, den 10. November 2016 um 17:30 Uhr im Simon-Bolivar-Saal in der Staatsbibliothek zu Berlin-Preußischer Kulturbesitz, Potsdamer Straße 33, 10785 Berlin-Tiergarten (S/U Potsdamer Platz) statt.

Im Anschluss gibt es die Möglichkeit, die sich ergebenden Fragen bei einem Snack und Getränken mit dem Vortragenden zu diskutieren.

Die Veranstaltung ist kostenlos. Bitte melden Sie sich trotzdem telefonisch (030-755 183 66) oder per Mail (bak[at]ub.tu-berlin.de) an.

Wir freuen uns auf Ihr Kommen.

Mit freundlichen Grüßen

Tania Estler-Ziegler
(Vorstandsvorsitzende)

Berliner Arbeitskreis Information (BAK)
c/o Universitätsbibliothek der TU Berlin
Fasanenstr. 88
10623 Berlin

Sehen Sie grün im StaBiKat!

Mit unserer neuen Verfügbarkeitsanzeige im klassischen StaBiKat erkennen Sie jetzt bereits in der Trefferliste, welche der gefundenen Medien Sie zeitnah lesen können. Dazu nutzen wir die bewährten Ampelfarben kombiniert mit einer beschreibenden Ausschrift. So können Sie gleich auf den ersten Blick erfassen, dass Sie ein gesuchtes Buch bestellen können und sparen viele Klicks!

Unsere Ampelfarben

Grün steht für aktuell verfügbare, bestellbare Bände und Präsenzbestand in den Lesesälen sowie für online verfügbare Quellen. Hierbei haben wir uns von Ihren Aussagen zu „verfügbar“ in der stabikat+ -Umfrage im letzten Sommer leiten lassen.
Gelb angezeigt werden verliehene, vormerkbare Bände aber auch einige ältere Werke mit dem Hinweis „Kriegsverlust möglich“, deren Daten wir in der nächsten Zeit noch korrigieren werden.

StaBiKat-Ausschnitt mit Verfügbarkeitsanzeige – Staatsbibliothek zu Berlin – PK / CC BY-SA-NC

Rot werden Werke gekennzeichnet, die nicht mehr in der Staatsbibliothek vorhanden oder langfristig nicht zugänglich sind, also Verluste oder vermisste Bände, die aber der Vollständigkeit halber weiterhin im StaBiKat angezeigt bleiben.
Graue Buttons sehen Sie, wenn zu einem Treffer mehrere Exemplare oder mehrere Bände gehören. Die Ampelfarben finden Sie dann erst nach dem nächsten Klick in der Detailanzeige des Treffers wieder.
Der farbige Button mit der zugehörigen Ausschrift führt entweder direkt zum Bestellen oder zur Detailanzeige im StaBiKat.

Snippets im Katalog?

Haben Sie unter einigen Suchergebnissen … Snippets … bemerkt? Snippets sind kurze Textauszüge. Im StaBiKat zeigen sie den Kontext des gesuchten Begriffes im Inhaltsverzeichnis des Bandes oder einer Rezension an, wenn Ihr Suchbegriff nicht in der Titelbeschreibung genannt ist.

Jetzt die neuen Funktionen testen

… und selbst den Mehrwert entdecken. Wir bieten Ihnen die Verfügbarkeitsanzeige zunächst im klassischen StaBiKat in einer Beta-Version an. Manche Einstellungen könnten sich noch ändern. Die komfortable Trefferanzeige möchten wir Ihnen aber nicht länger vorenthalten.

Verfügbarkeit demnächst auch in stabikat+

Für unsere Literatursuchmaschine stabikat+ ist die Einbindung der Verfügbarkeitsanzeige selbstverständlich ebenfalls aktuell geplant, um auch hier die Recherche für Sie noch attraktiver zu gestalten.

 

Relaunch der Digitalisierten Sammlungen

Relaunch der Digitalisierten Sammlungen mit flexiblem PDF-Download

Nach umfangreichen technischen Vorarbeiten hat unser Beta-Portal der Digitalisierten Sammlungen nun einen Reifegrad erreicht, der eine Umstellung des Produktivsystems erlaubt. Die NutzerInnen  können sich nun unter anderem auch über ein Feature-Revival freuen:

PDF-Download – aber richtig

Vor einiger Zeit sahen wir uns gezwungen, den bei Ihnen sehr beliebten PDF-Download abzuschalten, stattdessen wurden Bilder in einem .ZIP Archiv ausgeliefert. Der einzige Grund hierfür war eine Überlast unseres zentralen Servers. Der alte Prozess rechnete die hochauflösenden Bilder nach Anfrage des Downloads in eine mittlere Auflösung um, band sie dann in ein PDF zusammen und verschickte dies an die NutzerInnen. Dies führte regelmäßig zu einer Überlast des Imageservers, was in abgebrochenen Downloads resultierte. Die von anderen Einrichtungen oft gewählte Variante, alle PDFs vorzuberechnen und direkt aus dem Dokument-Management-System auszuliefern, war für uns nicht praktikabel: allein das Umrechnen der bestehenden 114.000 Werke hätte über ¼ Jahr gedauert.

Der nun vorgestellte Ansatz funktioniert gänzlich anders: die wesentlichen Rechenprozesse werden mit Hilfe von JavaScript/HTML5 (https://parall.ax/products/jspdf) auf die Rechner der anfragenden NutzerInnen ausgelagert. Auch mit älterer Hardware stellt dies in der Regel kein Problem dar, ermöglicht jedoch eine bisher auch bei anderen Portalen weltweit unbekannte Flexibilität: nicht nur der Seitenbereich kann selbst gewählt werden (auch auf Grundlage des Inhaltsverzeichnisses), sondern sogar die Auflösung der als PDF gebundenen Images kann frei bestimmt werden.

Jedes gescannte Pixel geht auch an die NutzerInnen

So führt ein Wert von 100 Pixeln Breite zu einem Thumbnail-Teppich im PDF, der von uns voreingestellte Durchschnittswert von 1.000 Pixeln ist ein guter Kompromiss von Lesbarkeit und Dateigröße, wir ermöglichen aber auch – ohne wenn und aber – den Download der vollständigen Scanauflösung. Natürlich wie immer ohne verunstaltende Wasserzeichen. Ich verfolge hier strikt die Devise: es ist nicht an uns als Bibliothek, Ihnen eine spezifische Nutzungsweise vorzuschreiben. Daher ist es unsere bewusste Strategie, eine maximale Flexibilität anzubieten.

pdf

Das Nutzerinterface des neuen PDF-Downloads

Um Ihnen die Entscheidung zwischen Qualität und Dateigröße zu vereinfachen, geben wir auf dem Download-Button direkt eine Hochrechnung an, wie groß die angefragte Datei in etwa sein wird. Hierbei ist wichtig zu wissen, dass es wirklich nur eine grobe Schätzung ist: die reale Dateigröße kann gut um bis zu 100% abweichen.

Ungenauigkeiten aushalten – für eine bessere User Experience

Diese Herangehensweise führte intern zu einigen Diskussionen: BibliothekarInnen schätzen keine Ungenauigkeiten, schon gar nicht in diesen Größenordnungen. Das übliche Vorgehen wäre, eine solche Angabe dann konsequent auszublenden. Ich hingegen bin der Auffassung, dass NutzerInnen die Information, ob der Download ca. 20 MB oder 200 MB groß sein wird, sehr wohl zu schätzen wissen. Die Größenordnung zählt – es ist demgegenüber einigermaßen egal, ob die Datei nun 15, 20 oder 25 MB groß ist.

Wege zum PDF

Sie erreichen den PDF-Download entweder aus der vollständigen Gliederung eines Werkes heraus, bei der Sie beliebige Strukturelemente wie Kapitel für den PDF-Download auswählen können. Oder aber Sie gehen über das Symbol des Werkzeug-Kastens im Bereich „Bild“.

Wege zum PDF-Download

Wege zum PDF-Download

Voraussetzung für die Funktionalität ist zum einen ein HTML5-fähiger Browser sowie aktiviertes JavaScript. Dem PDF vorangestellt wird eine Seite mit den grundlegenden bibliographischen Metadaten sowie dem persistenten Identifier. Für den Ausdruck ist es wichtig zu erwähnen, dass unsere PDFs keine Papiergröße (DIN A4 etc.)  vorgeben: im Druck-Dialog ist daher im Zweifel die Funktion „Auf Papiergröße skalieren“ zu aktivieren.

Der PDF-Download wurde maßgeblich von Tim Jabs realisiert, der erst vor wenigen Monaten seine Ausbildung als Fachinformatiker für Anwendungsentwicklung bei uns in der Abteilung Informations- und Datenmanagement (IDM) abgeschlossen hat.

Weitere neue Features der Digitalisierten Sammlungen wie Doppelseitenansicht, verbesserte Trefferliste, Expertensuche oder Responsives Design werden wir in separaten Beiträgen in Kürze hier veröffentlichen.

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.