Dokument_1.pdf (381 KB)

4. VuFind Anwendertreffen, Konstanz 7.10.2015

"Sind wir ein wenig füllig um die Hüften geworden?"

Günter Hipler, Projekt swissbib, Universitätsbibliothek Basel

Gedanken und Vorschläge hin zu mehr Komponenten und Flexibilität in der VuFind 2/3 Architektur basierend auf Zend Framework 3

Die „Potsdamer Kartoffel“ http://www.spektrum.de/news/um-die-hueften-fuelliger/600896

mandated by

I. Kurze Zusammenstellung der aktuellen VuFind2 / ZF2 Architektur

Outline

II. Gesammelte Erfahrungen in den letzten zwei Jahren: Was haben wir umsetzen können? Wo sind wir an gewisse Grenzen gestossen?

III. neue Möglichkeiten von ZF3 / PHP7 für die VuFind 3 Architektur

Überblick

Kurze Zusammenstellung der aktuellen VuFind2 / ZF2 Architektur

ZF2 Framework(häufig verwendete Koponenten) VF2 Prinzipien

Modulemanager

Eventmanager

Servicemanager

(Konfigurationen verstehenlernen!)

Viewkomponenten

Routing Translation Rendering

Theme-mechanismus(Vererbung!) Lokale

Module

viele mehr

swissbib / VuFind Präsentationskomponente

MVC Komponente

Unittesting CSS / Bootstrap3 /

Less /HTML5

JavaScript

„Clone andRun“

Was haben wir in swissbib auf Basis der bestehenden Architektur bisher umsetzen können?

Was haben wir umsetzen können ?

I. Implementation von Erweiterungsmodulen

juristisches Portal (jus.swissbib.ch)

Verwaltung von administrativen Datender beteiligten rd. 900 Institutionen(admin.swissbib.ch/libadmintest)

Integration der Ergebnisse des linked.swissbib.ch Projekts in der Präsentationskomponente

auf Basis eines ElasticSearch Index(vgl. https://github.com/linked-swissbib)

Erweiterungen für „swissbib classic“ einschliesslich baselbern.swissbib.ch

(vgl. https://github.com/swissbib/vufind)

Was haben wir in swissbib auf Basis der bestehenden Architektur bisher umsetzen können?

Was haben wir umsetzen können ?

II. Umfangreiche Themeerweiterungen

root

bootstrap3

sbvfrd

sbvfrdjus sbvfrdsingle sbvfrdmulti

a) von komplett eigener Oberfläche (bis Mai 2015 – grosser Aufwand aber klare Wiedererkennung des service)

b) danach Benutzung der ResponsiveDesign Implementierung von VF2 mit teilweisen Erweiterungen

Kurzes Fazit zur Architekturübersicht:

Kurze Zusammenstellung der aktuellen VuFind2 / ZF2 Architektur

→ Die VuFind Applikation basiert auf dem umfangreichen ZF2 Framework und hier insbesondere auf dem Model / View / Controller (MVC) Workflow

→ MVC basiert auf einer 'Vielzahl' von Komponenten deren Zusammenspiel von der Applikation verändert werden kann. VuFind nutzt diese Möglichkeiten des Eingriffs geschickt, indem es zum Beispiel eine eigene Themeimplementierung verwendet

Nachteile von MVC in der bestehenden Form:→ heavy-weight (der Durchlauf zur Verarbeitung eines REQUESTS zu einer RESPONSE) ist sehr aufwendig und ressourcenintensiv.

→ nicht für jeden Serviceaufruf die geeignete Form (Beispiele wo schlankere Abläufe wünschenswert sind: Covererstellung, Autosuggestion, ...)

Grenzen der aktuellen VF2 Architektur

Wo sind wir an gewisse Grenzen gestossen

III. Durchgehender Einsatz von schwergewichtiger ZF2 / MVC Architektur für jegliche Art von VuFind Funktionalität

II. Alle VuFind (Anwendungs)-Module plus alle abhängigen Komponenten sind in einem einzigen GitHub Repository enthalten.„Clone and Run“ Prinzip für die einfache Verwendung nicht technikaffiner Institutionen.

Problemfelder:- mangelnde Flexibilität- weniger optimale Umsetzung einzelner UseCases- Erinnerung an unsere „fülligen integrierten Bibliothekssysteme“

I. Verwendung von „Anwendungsmodulen“ anstelle von „Komponenten“.

Wo sind wir an gewisse Grenzen gestossen

„Anwendungsmodul“ versus „Komponente“

Meine Definition für 'Anwendungsmodul' im VuFind Kontext:„Code der vom ZF2 Module Manager bereitgestellt wird um Teil des MVC workflows zu sein“

HTTP Request Bootstrap Routing Dispatch Rendering HTTP

Response

..

Listeners

..

Listeners

..

Listeners

..

Listeners

Schema eines ZF2 „Model View Controller“ workflows:vgl. http://www.zend.com/en/webinars/recorded/show/340_the%20mvc%20architecture%20of%20zf2

ModuleManger (lädt Anwendungsmodule, die sich an Events registrieren)

VuFindModul

VuFindSearchModul

swissbibModul

any otherModule

Obwohl es möglich ist, auch Drittmodule als „libraries“ zu installieren, sehe ich das Modulkonzept nur im Design eines eher engen Anwendungskontexts und i.d.R. innerhalb von MVC.

So ist es viel schwerer einzelne Aspekte oder Funktionalität wie zum Beipiel Schnittstellen und Basisklassen für die Suche ausserhalb des eigentlichen VuFind Applikationskontextes zu verwenden.

Wo sind wir an gewisse Grenzen gestossen

weitere Zitate und Hinweise zur Abgrenzung von „Anwendungsmodul“ versus „Komponente“

Evan Coury (implementor of ModuleManager): http://www.zend.com/en/webinars/recorded/show/341_introducing%20the%20zend%20framework%202%20modulemanager „Resuable pieces of functionality that can be used to construct a more complex application“„ModuleManager – It's the component that will consume Module classes“„What can Modules be? Anything! Plugins, Themes, Libraries, Applications“

Enrico Zimuel: http://www.zend.com/en/webinars/recorded/show/340_the%20mvc%20architecture%20of%20zf2

„Resuable pieces of functionality that can be used to construct a more complex application“„A module is all related code and assets that solve a specific problem. Modules inform the MVC about services and event listeners.

Mike Willbanks : https://speakerdeck.com/mwillbanks/zf2-writing-service-components Modules are more specifically for ZF2 ApplicationsServiceComponents [GH.: libraries installed via Composer] are resusable libraries for any code baseBaseRule:If it involves the MVC; it should more than likely be a module.

Bisher einzige globale VuFind Komponente (vufind-org/vufindhttp):https://packagist.org/packages/vufind-org/vufindhttp zu anfang ebenfalls ein lokales Modul, dann Refactoring zur globalen Komponente

Wie könnten wir lokale Module in globale Komponenten aufteilen?

Wo sind wir an gewisse Grenzen gestossen

Globale Komponenten (Einbindung über Composer) - weniger Anwendungsmodule!

aktuelle Aufteilung Vorschlag global Components

Bootstrap VuFind Appliation

Interfaces / Basis Klassen für Suchtargets

Konkrete Implementierung des Targets

Einzig bisher verfügbarer globaler Service (zu anfang Anwendungsmodul)

singuläre Funktionalität

VuFind schwergewichtige MVC Implementierung (e.g. Controllers)

Anforderung: zusätzliche Abhängigkeiten

Wo sind wir an gewisse Grenzen gestossen

Problem: Nutzung zusätzlicher Bibliotheken die nicht bereits mit dem VuFind Repository mitgeliefert werdenmailing list thread: [VuFind-Tech] Local composer dependencies

http://sourceforge.net/p/vufind/mailman/message/34334936/

unsere aktuelle Lösung: lokale Abhängigkeiten parallel zum VuFind composer.json um Mergekonflikte zu vermeiden (wir sind mit dieser Lösung nicht sehr glücklich)

Mein Vorschlag für VuFind3:

- nicht mehr das „Clone and Run“ Prinzip anwenden- Abhängigkeiten zu Drittbibliotheken sollten nicht mehr Teil des VuFind Repositories sein.

evtl. als Mittelweg einen umfassenden, alle Abhängigkeiten enthaltenen Branch für jeden produktiven Release

https://github.com/linked-swissbib/vufind/tree/vfsb/linked/module/LinkedSwissbib/src/LinkedSwissbib/Backend/Elasticsearch

resources.swissbib.ch: verkleinerter MVC Workflow auf dedizierten Hosts

light MVC in swissbib für Covererstellung

'jeder' Request bedeutet immer noch (wenn auch hier vereinfacht und auf singulären host ausgelagert) :- Laden des Moduls- Laden der Konfiguration (vereinfacht duch Caching in Production)- Suchen nach der passenden Route- Bootstrapping des Moduls und Registrieren der EventManager- Controller Dispatching- Rendering (bei Cover nur Imagerückgabe)

unsere aktuelle Lösung (vor allem zur Verringerung der Last auf den Hosts):- Auslagerung der Covererstellung (immer noch lokales Modul) auf dedizierte Hosts mit angepasstem MVC Workflow https://resources.swissbib.ch/Cover/Show?isn=0133994619&size=small

- Nachteile:→ Codeverdoppelung da von VuFind keine dedizierten, globalen Komponenten angeboten werden → immer noch ZF2/MVC – aktuell keine Alternative vorhanden→ weniger Funktionalität (kein themerelevantes Rendering von Images, für uns nicht notwendig)

Gesucht: 'leichtgewichtige workflows'

Aktueller swissbib Ansatz für die Covererstellung:

Fazit:für spezifische und einfache Requests wie z.B. die Covererstellung oder Autosuggestion -die sehr häufig stattfinden- ist der klassische MVC eine hohe Belastung für den Server, langsamer in der Darstellung auf der Oberfläche und nicht notwendig!

Vorteile von globalen Komponenten und selbst installierten Dependencies

Zusammenfassung: Vorteile von globalen Komponenten und eigener Installation von Dependencies via Composer

1) Flexibere Nutzung von einzelnen Komponenten (durch VuFind selber aber auch durch Drittservices)

2) Merge Konflikte lassen sich leichter vermeiden

3) singuläre globale Repositories würden die Aufteilung der Verantwortung für die Implementierung von bestimmten Funktionen auf einzelne Institutionen erleichtern (Villanova, Finna, Finc, BSZ, swissbib ….. )

4) leichtere Versionsverwaltung: nicht alle Komponenten ändern sich gleich häufg

Erster Ausblick auf Änderungen im neuen ZF3

Ausblick auf Umstellungen im kommenden Zend Framwork 3

1. Aufteilung des singulären ZF2 Repository in viele einzelne Repositories

2. Umsetzung des PHP Specification Request 7 (PSR7) innerhalb des Zend Frameworks als Grundlage für neue sog. 'Middlewarecontainer'

3. Refactoring zentraler Komponenten des Zend Frameworks (vor allem Service Manager und EventManager) https://github.com/zendframework/zend-eventmanager/pull/4 https://twitter.com/mwop/status/643545615478226945

neue Aufteilung des Frameworks in singuläre globale Komponenten mit Metarepository

Aufteilung des singulären Repositories in viele einzelne Komponenten

Why split them at all?"But you can already install components individually!" True, but if you knew how that occurs, you'd cringehttps://mwop.net/blog/2015-05-15-splitting-components-with-git.html

Version < 2.5 Framework in einem Repository (vergleichbar mit dem aktuellen VF2)https://packagist.org/packages/zendframework/zendframework

neue Aufteilung des Frameworks in singuläre globale Komponenten mit Metarepository

ZF2 Repositoryaufbau ab 2.5 (Vorbereitung für ZF3)

Version >= 2.5: insgesamt rund 50 einzelne Repositories

https://packagist.org/packages/zendframework/zendframework

2. Umsetzung des PHP Specification Request 7 (PSR7) innerhalb des Zend Frameworks

neue Möglichkeiten von ZF3 / PHP7 für de VuFind 3 Architektur

PSR 7 in Kürze: einheitliche Interfaces zur Repräsentation von HTTP Nachrichten und URIs

http://www.php-fig.org/psr/psr-7/https://mwop.net/blog/2015-01-26-psr-7-by-example.html https://mwop.net/blog/2015-01-08-on-http-middleware-and-psr-7.html http://blog.alejandrocelaya.com/2015/09/12/my-first-approach-to-zend-expressive/

standardisierte PSR7 Interfaces als Basis für Middleware Software

Zend Middlewarezend-stratigility

zend-expressivezend-diactoros

s. https://github.com/zendframework

Symphony Middlewarehttp://symfony.com/blog/psr-7-support-in-symfony-is-here

otherimplementationsfor Middleware

Müssen wir wegen der neuen Zendversion wie beim Wechsel von VuFind1 zu VuFind2 alles umstellen?

Ausblick auf Umstellungen im kommenden Zend Framwork 3

→ Anpassungen der zentralen Komponenten bekommen wir nahezu 'umsonst' (kleinere Anpassungen in den Schnittstellen ausgenommen)

→ wir 'müssen' kaum etwas umstellen!

→ für VuFind 3 'sollten' wir jedoch die Chance eines Refactorings auf Basis der genannten Erweiterungen (Middleware sowie singuläre Komponenten anstelle von 'Anwendungsmodulen') nutzen, um die geschilderten Schwächen zu beseitigen plus neue zusätzliche Möglichkeiten für Erweiterungen und Flexibilität zu erreichen.

Middleware in a Nutshell

Aufbau eines Middlewarestack

- Middleware als Rahmen (Container) für die Umsetzung eines Requests in eine Response

- Middleware kann, wie in Schalen, verpackt aufeinander aufbauen.

- jede Schale benutzt die einheitlichen Schnittstellen des PSR7 zum Austausch der Daten vom REQUEST und für die RESPONSE

- durch die einheitlichen Schnittstellen können die Container unterschiedliche Aufgaben übernehmen und durch alternative Implementierungen ausgetauscht werden

http://www.zend.com/en/webinars/recorded/show/3033_stratigility%20middleware%20for%20php%20and%20psr-7

https://www.youtube.com/watch?v=B2YqevRpi6E

Middleware in a Nutshell

Möglichkeiten für den Zusammenbau von Middlewarecontainern

Komposition von „Middleware-schalen“:

Authentication /Authorization

VF / Favorites(ZF2 / MVC)

Request

Response

Response(Error)

Middleware in a Nutshell

Möglichkeiten für den Zusammenbau von Middlewarecontainern

Einsatz unterschiedlicher Middleware

VF / Search(ZF2 / MVC)

RequestSearch?lookfor=hello

Response

Response(Error)

„schwergewichtige“ ZF2 / MVC Implementierung

VF Cover / Autosuggest

(lightweight Middleware)

RequestCover/123456

Response

Response(Error)

„leichtgewichtige“ Middleware für den Request von Images / Autosuggest

Middleware in a Nutshell

neue Möglichkeiten von ZF3 / PHP7 für de VuFind 3 Architektur

Einsatz unterschiedlicher Middleware

REST API

Request/api?q=hello world

Response

Response(Error)

- REST API Container - basierend auf Zend apigility (https://apigility.org)- ausgewählte einzelne Repositories implementieren die Funtionalität

linked.swissbib.ch(dependencies:

vufind_corevufind_search_base

swissbib_backend_elasticsearch)

vufind - functionality provided via API(proposal Finna)

(dependencies: vufind_core

various additional componentscould be deployed on dedicated infrastructure)

Wie kann ein Middlewareaufbau im Code aussehen?

mögliche Zusammenstellung von Middleware als einfaches Codebeispiel

weitere praktische Codebeispiele:https://github.com/zendframework/zend-expressivehttp://blog.alejandrocelaya.com/2015/09/12/my-first-approach-to-zend-expressive/

PHP 7 und Vorschlag für einen gestaffelten PHP Umstieg in VuFind

current VuFind Versionout of support!

Kurzinfos zu PHP 7 (produktiver Release im Oktober 2015) :Zend Engine geriet durch die Entwicklung der Facebook HHVM unter Druck → grundlegende Anpassungen und Überarbeitungen → grosse Performanceverbesserungen → TypeHints → ZF3 Minimum: PHP 5.5 / wird gegen PHP 7 getestet https://www.zend.com/en/resources/php7_infographic

Mein Vorschlag welche PHP Versionen wir einsetzen sollten:VF2 → Wechsel zu PHP 5.5 / PHP 5.6VF3 → Entwicklung wird gegen PHP 7 getestet ab 2. Hälfte 2016 Umstellung der Requirements auf PHP 7

Übersicht der aktuellen PHP Versionen

mögliche nächste Schritte ?

Vorschlag nächste Schritte nach dem VuFind Anwendertreffen in Konstanz 2015

→ VuFind Summit: Oktober 2015 Start Diskussion der VuFind 3 Roadmap (an dieser Diskussion sollten viele teilnehmen / ein Grund für diesen Vortrag / englische Übersetzung folgt)

→ Diskussion sollte nicht nur am VuFind Summit stattfinden. Alle aktiven 'coders' sollten in den nächsten Wochen damit beginnen, sich mit den neuen zusätzlichen Möglichkeiten der aktuellen zu PHP und Zend vertrauter zu machen. Dies würden sehr helfen, ein verbessertes Design für die Architektur von VuFind 3 zu finden.

→ Hierfür müssen wir nicht warten, bis das Release von Zend Framework 3 erscheint. Zentrale Komponenenten sind bereits jetzt vorhanden und werden bis zum Release nur noch verbessert. Um es nochmals zu erwähnen: Eine wichtige Voraussetzung, die Aufteilung in einzelne globale Komponenten geschah bereits mit der Version >= 2.5

https://github.com/zendframework/zend-stratigility https://github.com/zendframework/zend-diactoros https://github.com/zendframework/zend-expressive https://apigility.org/ (für Schnittstellen basierend auf REST Prinzipien)

Diskussion / Fragen / Buhrufe / Begeisterung ??

wie kann mich direkt erreichen:guenter.hipler@unibas.chTel.: +41 61 267 31 12

Links für weitere Infos zu den swissbib Projekten und unseren Rahmenbedingungen

Blog: http://swissbib.blogspot.ch/ Twitter: www.twitter.com/swissbib Projektwiki: www.swissbib.org (Memberstatus mit kurzem mail)Code swissbib: https://github.com/swissbib (swissbib „classic“)Code linked-swissbib: https://github.com/linked-swissbibProjektmail: swissbib-ub@unibas.ch

SUK-Programm 2013-2016 P-2 «Wissenschaftliche Information: Zugang, Verarbeitung und Speicherung»

http://www.swissuniversities.ch/de/organisation/projekte-und-programme/suk-p-2-wissensch-information-zugang-verarbeitung-speicherung/