Heute mal was ganz anderes: ich führe ein Interview mit Oliver Gierke von SpringSource . Los geht’s …
Tobias Trelle: Hallo Oliver. Möglicherweise gibt es Leser, die Dich noch nicht kennen. Könntest Du Dich bitte kurz vorstellen?
Oliver Gierke: Mein Name ist Oliver Gierke. Ich arbeite für die SpringSource Division bei VMware im Spring Data Engineering Team. Hierbei bin ich für die Entwicklung des Kernmoduls, des JPA-Moduls und des MongoDB-Moduls zuständig. Darüber hinaus organisiere ich das Releasemanagement aller Spring Data Module die auf das Core Modul aufsetzen und bin viel auf Konferenzen und bei Usergroups unterwegs um über die Projekte zu reden.
Vorher habe ich viele Jahre als Architekt und entwickler im Banken- und Automobilumfeld gearbeitet. Weiterhin bin ich Teil der JPA Expert Group
TT: Wie bist Du damals zu SpringSource und zum Spring Data-Projekt gekommen?
OG: Mein damaliger Arbeitgeber, die Synyx GmbH & Co. KG in Karlsruhe setzt bei der Umsetzung ihrer Kundenprojekt stark auf OpenSource Software. Dies beinhaltet unter anderem, dass wir – insofern das die Kundenprojekte erlaubten – Programmierbibliotheken aus den Projekten extrahiert und unter OpenSource Lizenz veröffentlicht haben. Eine dieser Bibliotheken war Hades. Sie basierte auf einem Artikel bei IBM DeveloperWorks und einem weiteren von Eberhard Wolff im JavaMagazin, die beide Ideen formulierten, wie der Aufwand, Datenzugriffsschichten mit Hibernate bzw. JPA signifikant reduziert werden kann.
Es gab zu der Zeit keine OpenSource Implementierung dieser Ideen und so starteten wir das Projekt bei Synyx und nutzen es in unseren Kundenprojekten. Es begann ein reger Austausch mit Eberhard, der im Zusammenspiel mit meinem breiten Springhintergrund dann dazu führte, dass ich eine Weile später angefangen habe bei SpringSource angefangen zu arbeiten.
Zu dieser Zeit war gerade das Spring Data Projekt entstanden und dessen Lead, Mark Pollack, kontaktierte mich mit der Bitte, doch mal zu evaluieren ob Hades im Kontext von Spring Data Sinn machen würde (um so ein JPA Modul zu gründen) und in wieweit es möglich ist, die Repositoryabstraktion die in Hades bzw. Spring Data JPA implementiert waren über anderen Stores Sinn machen würde. Wir haben dann an einem Wochenende die JPA-unspezifischen Teile von den JPA-spezifischen getrennt und kurz darauf einen ersten Entwurf der MongoDB-spezifischen Implementierung gebaut. Das war dann auch mein Einstieg in die anderen Spring Data Module.
TT: Spring Data unterstützt sowohl relationale als auch NoSQL-Datenbanken. Wie passt das unter einen Hut? Gibt es da wirklich so viele Gemeinsamkeiten?
OG: In der Tat ist das die große Herausforderung. Gerade die verschiedenen NoSQL Datenbanken werden ja jeweils aufgrund ihrer besonderen Eigenschaften ausgewählt. Wir sind im Team dann übereingekommen, dass es wenig Sinn macht zu versuchen, allen Stores ein einheitliches API (z.B. JPA) überzustülpen, da das bedeuten würde, dass man beim kleinsten gemeinsamen Nenner landet und viele interessante Features der Stores wie z.B. Map-Reduce in MongoDB oder Graphentraversierung in Neo4j eben nicht verallgemeinert abgebildet werden kann.
Uns kommt an dieser Stelle der Fakt, dass wir auf Spring aufsetzen auf eine sehr spannende Art und Weise entgegen. Es ist nicht nur die technologische Grundlage mit Dependency Injection, der Unterstützung zum Implementieren einfacher, store-spezifischer Konfiguration usw. Es ist vielmehr, dass Spring sehr konsistent bestimmte Patterns implementiert und es eine Art „Spring Weg“ gibt, bestimmte Probleme zu lösen. Spring Entwickler kennen alle das JdbcTemplate, das JmsTemplate usw. Die sind natürlich alle anders, da sie verschiedene Technologien abstrahieren, funktinieren dennoch immer nach dem gleichen Muster, haben die gleichen Aufgaben.
Diesen Ansatz verfolgen wir jetzt eben auch mit dem Spring Data Projekt. Ziel ist es ein konsistentes Programmiermodell auf Spring Basis anzubieten und dabei die Eigenheiten der Stores weiter zu exponieren um sie dediziert nutzen zu können. D.h. dass für jemanden der aktuell Spring Data Repositories mit JPA nutzt, der Umstieg auf MongoDB sehr leicht sein sollte, da die Repositories zu 90% genauso ausschauen.
TT: Es gibt sehr viele NoSQL-Datenbanken. Wie kam es zu der Entscheidung, ausgerechnet MongoDB, Neo4j, Redis und Gemfire zu supporten?
OG: Die Auswahl der zur Zeit unterstützten Stores folgt hauptsächlich der Nachfrage die wir im Markt sehen. MongoDB ist momentan wohl der Platzhirsch unter den Allzweck-NoSQL-Datenbanken. Das Neo4j Module wird sehr stark von Michael Hunger von NeoTechnologies, der Firma hinter Neo4j getrieben und war eigentlich das erste Spring Data Modul überhaupt. Die Unterstützung für Redis und Gemfire ist darauf zurückzuführen, dass beide Technologien VMware-Produkte sind und wir natürlich darauf bedacht sind erstklassige Spring-Unterstützung dafür anzubieten.
Wir bekommen natürlich auch regelmäßig Nachfragen bzgl. anderer Stores wie z.B. Cassandra. Momentan liegt allerdings eher der Fokus darauf Fokus zu behalten und sich nicht in zu vielen Storeimplementierungen auf einmal zu verlieren. Mit Spring Data Solr hat vor kurzem das erste komplett Community-getriebene Modul einen ersten Milestone veröffentlicht, was wir aktiv unterstützen. D.h. jegliche Aktivität in der Community wird von uns interessiert beobachtet und auch unterstützt.
TT: Wie sieht die Roadmap für die weitere Entwicklung von Spring Data aus? Mit welchen Features können wir in Zukunft rechnen?
OG: Mit den Veröffentlichungen Anfang Oktober haben wir neue stabile Versionen des Spring Data Core Moduls und den darauf aufbauenden Modulen JPA, MongoDB, Neo4j und Gemfire. Der Fokus liegt für diese jetzt auf der nächsten Majorgeneration in der wir vmtl. ein paar grundlegende Änderungen umsetzen können. Das Auditingfeature aus dem JPA Modul wird zum Teil in den Core wandern und dann auf die anderen Stores ausgeweitet. Desweiteren werden wir ein paar fortgeschrittene Einsatzszenarien wie das Erweitern der Repository API vereinfachen. Grundsätzlich ist das in der aktuellen Version natürlich schon implementierbar, das Programmiermodell hat jedoch hier und da ein paar Stellen, die noch einfacher sein könnten. Darüber hinaus beobachten wir natürlich das Communityfeedback und implementieren Unterstützung für neue Features in den speziellen Stores.
Neben den Modulen für die individuellen Stores gibt es noch mit Spring Data REST ein relativ junges Projekt unter dem Spring Data Schirm. Mit ihm kann man sehr einfach Spring Data repositories als Hypemedia-getriebene REST Resourcen veröffentlichen um sehr einfach per HTTP mit Daten zu arbeiten. Es deckt damit den typischen 80% use-case ab, verfügt über dedizierte Konfigurationsmöglichkeiten um genau steuern zu können, was wie veröffentlicht wird. Darüber hinaus gibt es viele Punkte, mit denen man das Modul mit eigegem Code anreichern und anpassen kann.
TT: Mit Spring Data seid ihr dem JEE-Stack (mal wieder) meilenweit voraus. Rechnest Du damit, dass die NoSQL-Ideen mittelfristig in JEE Einzug halten werden?
OG: Das weiß ich ehrlich gesagt nicht. Ich habe ja schon in der Antwort auf die Frage nach den großen Unterschieden in den verschiedenen Stores herausgestellt, dass genau hier das größte Problem besteht. D.h. ich sehe aktuell keinen sinnvollen Weg, diesen Problemraum sinnvoll unter einer einzelnen API zu standardisieren.
Es gibt aus verschiedenen Richtungen Versuche NoSQL Stores hinter einem JPA Layer zu abstrahieren. Das ist relativ schwierig weil die Spezifikation viele relationale Konzepte nach aussen trägt, Transaktionen vorraussetzt usw. D.h. im besten Fall kann man ein sehr schmales Profil der JPA implementieren, was auch genau das ist was diese Ansätze erreichen. Wenn ein Entwickler nun also gesagt bekommt: „Hier ist JPA für NoSQL“ und dann eine seitenweise Auflistung von Punkten folgt, die eben nicht funktionieren ist der Mehrwert den das Nutzen von JPA in diesem Fall bietet eher gering. An diesem Punkt haben wir noch gar nicht davon gesprochen, wie man denn eben store-spezifische Features benutzt, die vermutlich ein wichtiger Grund sind, warum man exakt diesen Store ausgewählt hat.
Zusammenfassend sehe ich im mittelfristigen Zeithorizont keine Standardisierung des Datenzugriffs auf NoSQL Datenbanken auf uns zukommen. Wobei mittelfristig in diesem Fall JavaEE 8 bedeuten würde, was frühestens in 3 Jahren kommt. Ich glaube, so lange werden Java-Entwickler nicht warten können.
TT: Vor kurzem ist das Buch Spring Data – Modern Data Access for Enterprise Java erschienen. Du bist einer der Autoren. Wie ist die Idee zu diesem Buch entstanden?
OG: O‘Reilly kam während der SpringOne 2011 in Chicago auf uns zu und fragte ob wir als Team Lust hätten ein Buch über das Projekt zu schreiben. Wir wollten das Buchprojekt dann einfach als Chance nutzen dem interessierten Entwickler einen breiten Überblick über das Projekt zu geben und anhand von praktischen Beispielen aufzeigen, wie einfach es heutzutage sein kann mit relationalen und nicht-relationalen Datenbanken zu arbeiten. Man bekommt also auf ca. 300 Seiten einen guten Eindruck von den einzelnen Modulen, in welchem Einsatzszenario diese Sinn machen und wie man damit unsere Beispieldomäne – ein Onlinestore – implementiert.
TT: Als Autoren wart ihr über den ganzen Globus verstreut. Wie hat die verteilte Zusammenarbeit funktioniert?
OG: Die Arbeit am Buch unterschied sich relativ wenig von der alltäglichen Arbeit am Projekt selbst. Die meisten Kapitel wurden von den Autoren der jeweiligen Module geschrieben, die restlichen allgemeinen Kapitel unter den Autoren aufgeteilt. Buchprojekte ziehen sich erfahrungsgemäß immer etwas und es ist natürlich erstmal zusätzliche Arbeit neben dem eigentlichen Projektalltag. Da wir allerdings zu 6. waren haben wir das Buch in etwas über 2 Monaten schreiben können und passend zum kürzlich veröffentlichten Releasetrain einiger Spring Data Module fertigstellen können. Da wir Autoren zu sehr unterschiedlichen Teilen am Buch beteiligt waren haben wir uns dafür entschieden, den Gewinn, den das Buch erzielt, an die Creative Commons Organisation zu spenden.
TT: Arbeitest Du noch an anderen Projekten? In letzter Zeit höre ich des öfteren das sperrige Akronym HATEOAS …
OG: Ben Hale, ein Kollege bei SpringSource nannte es einmal „das Wort ohne richtige Aussprache“. Spring HATEOAS ist eine recht kleine und junge Bibliothek die ebenfalls in Projekten entstanden ist, in denen ich Kunden dabei geholfen habe Hypermedia basierte REST WebServices zu implementieren. Für viele grundsätzliche Problemstellungen im REST Bereich wie Request-Mapping und Content-Negotiation bieten die gängigen Java Webframeworks gute Unterstützung. Geht es allerdings um die Implementierung von Hypermedia, d.h. das anreichern von Representationen mit Links und somit der Umsetzung der Entdeckbarkeit von REST Webservices ist faktisch keine Unterstützung präsent. Spring HATEOAS stellt nun Hilfsklassen und APIs bereit um genau diese Lücke zu schließen.
Das Spring Data REST Module z.b. nutzt diese Bibliothek um Entitäten die mit einem Spring Data Repository verwaltet werden automatisch als Hypermedia-getriebene REST WebServices zu exportieren. Ein sehr hübsches Beispiel dafür, wie die verschiedenen Spring Projekte ineinandergreifen und dem Entwickler Arbeit abnehmen. In meinem GitHub Account gibt es dazu eine Beispielimplementierung (http://github.com/olivergierke/spring-restbucks ) des Use-Cases aus dem „REST in Practice“ Buch von Jim Webber, Ian Robinson und Savas Parastatidis. In ihr werden Spring Data JPA, REST und das Spring HATEOAS Projekt verwendet.
TT: Würdest Du dich als Konferenz-Junkie bezeichnen? Wenn man in Dein Twitter-Account schaut, scheinst Du ständig auf Konferenzen unterwegs zu sein. Wann arbeitest Du an Deinen Spring-Projekten?
OG: Der Herbst ist traditionell vollgepackt mit Konferenzen und das letzte Spring Data Release sowie die Veröffentlichung des Buches sind natürlich Dinge, die ich gern in die Welt trage und Entwicklern davon berichte. Ein weiterer Aspekt ist natürlich, dass die Konferenzengagements ein wichtiger Feedbackkanal für uns sind um sicherzustellen, dass wir verstehen, wo Entwicklern der Schuh drückt.
Die Reiserei ist natürlich schon anstrengend, aber Zeit zum Entwicklen findet man eigentlich immer, sei es im Hotel, auf der Konferenz selbst usw. Abgesehen davon ist das Programmieren im Flugzeug die reinste Form des Cloud-Computing, oder?
TT: Auf welchen Konferenzen kann der Leser Dich als nächstes Treffen?
OG: Ich bin Anfang Dezember auf Asientour in Peking, Tokio, Hyderabad und Bangalore. Anfang 2013 geht als erstes mit der OOP in München los, bei der ich über Spring HATEOAS und Spring Data REST sprechen werde. Für alles folgende laufen momentan noch die Planungen.
TT: Vielen Dank für das Interview.
OG: Sehr gern, vielen Dank, Tobias!
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Trelle
17.12.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Trelle
Software Architect
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.