Deutschland 9,80. Der unbekannte Dritte 45. IDE-Integration mit der Spring Tool Suite 38

Transkript

1 Neo4j-Tutorial: Graphdatenbanken zum Anfassen 82 Java Mag Deutschland 9,80 Österreich 10,80 Schweiz sfr 19,50 Luxemburg 11, magazin Java Architekturen Web Agile Elasticsearch Suche mit anderen Augen 69 Die Zukunft des Frühlings Java EE und der ACC Der unbekannte Dritte 45 Spring IO Alle Infos hier im Heft! 22 Spring mit neuem Look und neuem Feel? 32 IDE-Integration mit der Spring Tool Suite 38 Spring Boot: New Kid on the Stack 42 istockphoto.com/_rike_ Mehr Themen: Java ME 8 und Embedded: Back to the Roots 106 FX Traits: JavaFX und Scala Traits kombiniert 90 Sencha trifft REST: Mobile HTML5-Apps auf Knopfdruck 101

2 Titelthema Spring IO Was es mit der neuen Plattform auf sich hat Die Zukunft des Frühlings Auf der diesjährigen SpringOne-Konferenz in Santa Clara kündigte das Spring-Team die Plattform Spring IO an, einen komplett neuen Ansatz, die Spring-Technologien zu nutzen. Wir werfen einen Blick auf die Plattform und erläutern, was genau dahintersteckt. von Oliver Gierke istockphoto.com/_rike_ 32 javamagazin

3 Spring IO Titelthema Spring ist wohl das populärste und am weitesten verbreitete Framework zur Entwicklung von Unternehmensanwendungen in Java. Eine Vielzahl völlig verschiedener Anwendungstypen wird auf ihm implementiert: Einfache Webapplikationen, anspruchsvolle Serverapplikationen, aber auch Batchprozesse und Software im Bereich der Applikationsintegration gehören zum klassischen Einsatzfeld des Frameworks. Unbestreitbar ist auch der hohe Einfluss in Spezifikationen für Dependency Injection wie in Java EE 5. Auch neuere Spezifikationen wie JTA 2.1 (JSR und JSR 352 für Batchapplikationen in Java tragen eindeutig die Handschrift der entsprechenden APIs und Module des Spring Frameworks. Die technischen Anforderungen an Softwaresysteme haben sich in den letzten Jahren allerdings auch stark verändert. Während es vor fünf Jahren vielleicht noch genügte, mit einer relationalen Datenbank zu sprechen und in ihr enthaltene Daten in einer Webansicht anzuzeigen, trifft man heutzutage nicht selten auf eine Kombination aus relationalen und nicht relationalen Datenbanken, der Anforderung zu OAuth-Security, der Integration mit sozialen Netzwerken oder dem Bearbeiten von extrem großen Datenbeständen, zeitkritischen Daten usw. Auch für diese Herausforderungen bietet Spring Unterstützung an. Schon immer bestand das Spring-Ökosystem aus verschiedenen Modulen, die den Aspekten der unterschiedlichen Applikationstypen Rechnung trugen. Der Vorteil hierbei besteht darin, dass eine Applikation exakt die Teile von Spring benutzt, die sie benötigt. Umgekehrt sorgt das konsistente Programmiermodel der einzelnen Module dafür, dass die Einarbeitungszeit in einen bisher unbekannten Teil des Ökosystems überschaubar bleibt sich Entwickler schnell zu Hause fühlen, auch wenn man sich in technisch neues Terrain begibt. Ein gutes Beispiel hierfür ist die Repository-Abstraktion der Spring Data Module: hat man sich zum Beispiel einmal im Bereich JPA daran gewöhnt, in dieser Herangehensweise Datenzugriff zu implementieren, ist der Umstieg auf einen MongoDB-basierten Datenzugriff mit gleicher Technologie sehr einfach. Es wird Entwicklern also sehr leicht gemacht, einmal erworbenes Wissen in andere Kontexte zu übertragen. Herausforderungen Der modulare Aufbau des Frameworks erlaubt es den Einzelprojekten, sich in unterschiedlicher Geschwindigkeit zu bewegen, andere Releasezyklen zu wählen. Während das Spring Framework seit mehreren Jahren kontinuierlich auf einem Ein-Jahres-Rhythmus für Majorversionen ist, bewegen sich z. B. die Spring Data Module in einem etwa sechs-monatigen Zyklus. Grund dafür sind unter anderem unterschiedliche Releasezyklen der Dritttechnologien, die es zu integrieren gilt: Der Lebenszyklus einer Java-EE- oder JDK-Spezifikation, die Spring 4 sehr stark beeinflusst, unterscheidet sich von dem eines MongoDB-Treibers, der wiederum eine wichtige Abhängigkeit des Spring Data MongoDB Moduls ist. Die Konsequenz daraus ist die Notwendigkeit, Kompatibilität zwischen den entsprechenden Modulen des Spring Frameworks sicherzustellen und es den Entwicklern möglichst einfach zu machen, die Module in kompatiblen Versionen zu konsumieren. Die Plattform Um mehr Überblick über das Ökosystem zu geben, definiert die Spring-IO-Plattform den Teilbereich Foundation. Dieser Bereich illustriert die verfügbaren Spring Module und wie diese zueinander in Beziehung stehen und definiert so die Basistechnologien des Stacks. Im Bereich Core findet man wie erwartet das Kernframework, sowie die bekannten Technologien Spring Security und Groovy. Mit Spring 4 gibt es in diesen Tagen das erste Mal seit vier Jahren eine neue Majorversion des Kernframeworks. Enthalten sind die Unterstützung für Java 8, die wichtigsten Java-EE-7-APIs, WebSockets, Groovy-basierte Bean-Definitionen und ein überarbeiteter Dependency-Injection-Mechanismus mit Unterstützung für Applikationskomponenten mit Generics. Neu in diesem Bereich ist sicher Project Reactor, ein Basisframework für Reactive Programming. Reactor ist eine Basistechnologie, die es erlaubt, hochperformante, eventbasierte Anwendungen zu implementieren. Im Bereich der Persistenz erweitern vor allem die Spring-Data-Projekte den Funktionsumfang des Kernframeworks. Im relationalen Bereich bieten die Module für JPA und JDBC die umfassendste Unterstützung für Entwickler, möglichst effizient Datenzugriff zu implementieren. Im nicht relationalen Bereich gibt es hier Unterstützung für die Platzhirsche MongoDB, Neo4j und Gemfire. Besonders hier ist allerdings auch die Spring-Community sehr aktiv und bereichert das Portfolio durch Module für Couchbase, Solr und Elasticsearch. Während die unteren zwei Layer unserer Architektur sehr universell einsetzbare Technologien beschreiben, ist der obere Teil der Foundation schon sehr an den verschiedenen Applikationstypen orientiert, die sich mit Spring implementieren lassen. Hierzu gehört zum Beispiel Spring Integration, eine Implementierung der Enterprise Application Integration Patterns des gleichnamigen Buchs von Gregor Hohpe. Spring Batch war lange Zeit das einzig verfügbare Framework für die Implementierung von Batchszenarien und wird in der kommenden Version 3.0 aufgrund seiner Reife wohl die wichtigste Implementierung des JSR-352-Standards. Im Bereich der Big-Data-Applikationen hat sich in der Java-Welt vor allem Spring Hadoop einen Namen gemacht, da es Apache Hadoop konsistent in eine Spring-Applikation einfügt und Entwicklern gewohnte Programmiermodelle bereitstellt. Im Bereich Web sind die altbekannten Module Spring MVC und Spring WebFlow zu finden, sowie Unterstützung für Legacy- Technologien wie SOAP (durch Spring Web Services) javamagazin

4 Titelthema Spring IO IO Execution Auf den Bereich der Foundation setzt nun der Execution- Bereich auf. Wie der Name schon vermuten lässt, finden sich hier Laufzeitumgebungen, die zum Teil nicht mehr einfach Bibliotheken sind, sondern Ausführungs-Container für Applikationen einer bestimmten Klasse. Das Spring-Team spricht hier von Domain-specific Runtimes (DSRs), wobei Domäne hier noch den technischen Bereich beschreibt, in den sich die Applikation einordnet. Die klassischste und wohl auch bekannteste Ausführung solch einer Laufzeitumgebung ist Grails. Es hilft Entwicklern, sehr schnell und produktiv Groovy-basierte Webapplikationen zu bauen, in dem es Projektstruktur vorgibt, und auch zur Laufzeit den Applikationen Funktionalität beisteuert. Spring XD ist noch ein sehr junges Projekt, das sich dem Bereich Big Data Processing annimmt und ähnlich wie Grails die für die Problemlösung relevanten Spring-Technologien bündelt und zusätzlichen Mehrwert in Bezug auf Monitoring und Operations bietet. Eine Vorstellung von Spring XD findet sich unter [1]. Ein ebenfalls neues Projekt im Portfolio ist Spring Boot, entstanden aus verschiedenen Ideen der letztjährigen SpringOne Eberhard Wolff und Martin Lippert gehen im Folgenden detailliert auf Spring Boot ein, daher hier nur ein paar erste Informationen. Spring Boot Spring Boot ist ein sehr zentraler Bestandteil der Spring-IO-Plattform. Das Projekt geht drei wesentliche Aspekte der Anwendungsentwicklung bei Spring- Applikationen an: Abb. 1: Spring IO Platform Stack aber auch unentdecktere Aspekte wie Hypermedia im Bereich REST Web Services (durch Spring HATEOAS). Interview mit Jürgen Höller Auf der W-JAX 2013 traf Claudia Fröhling auf Jürgen Höller, um über die neue Plattform, das anstehende Spring-Framework-Release und die Chancen von Java 8 zu sprechen Vereinfachtes Dependency Management 2. Automatische Defaults in der Anwendungskonfiguration 3. Vereinfachtes Deployment und Betrieb von Java- Applikationen Vereinfachtes Dependency Management Wie oben bereits angesprochen, ist das Verwalten von Abhängigkeiten eine kritische Aufgabe in Softwareprojekten. Im Spring-Umfeld ist es die Aufgabe der Entwickler und Architekten zu definieren, welche Abhängigkeiten ein System benötigt und in welcher Version diese benutzt werden sollen. In alternativen Ansätzen zum Beispiel einem Java EE Application Server scheint diese Herausforderung nicht zu bestehen, da dieser bereits vordefinierte Implementierungen der jeweiligen Spezifikationen mit ausliefert. Was auf den ersten Blick eine einfache Lösung zu sein scheint, hat allerdings auch gravierende Nachteile. Erstens wählt der Serverhersteller die Bibliotheken aus, nicht das Team selbst. Die Auswahl ist also nicht unbedingt von den Anforderungen im Projekt getrieben ( Kann der JPA-Provider überhaupt mit einem Datenbankschema umgehen, das wir nutzen müssen? ), sondern von in Bezug auf das Projekt recht willkürlichen Anforderungen. Zweitens stellt sich die Herausforderung der manuellen Abhängigkeitsverwaltung in Projekten sowieso, sobald dieses nicht standardisierte Bibliotheken einsetzt und sie als direkte Abhängigkeiten verwendet. Drittens ist man in diesem Modell mit seinen Applikationen sehr stark an den Lebenszyklus der Deployment- Plattform gebunden. Stolpert man z. B. über einen Bug in einer im Server betriebenen Bibliothek, ist es unter Umständen nicht ohne Weiteres möglich, eine neuere Version dieser Bibliothek zu verwenden, die den Bugfix evtl. schon enthält. Der lange Lebenszyklus der Plattform hat weiterhin den Nachteil, dass eben Upgrades derselben nur nach sehr langen Zeiträumen möglich sind bzw. 34 javamagazin

5 durchgeführt werden. Für den im Frühjahr verabschiedeten Java-EE-7-Standard gibt es von den großen Herstellern leider auch über ein halbes Jahr später noch immer keine offiziell unterstützte Serverversion. Im Umfeld von Spring-Applikationen ist es also üblich, den exakt anderen Weg zu gehen: die toolgestützte, manuelle Verwaltung von Abhängigkeiten und deren Versionen sowie das Deployment eben dieser als JARs im Applikationsartefakt. Auch dies ist natürlich nicht ohne Herausforderungen: Besonders das Zusammensuchen von kompatiblen Versionen hat so manchem Entwickler und Architekten das ein oder andere graue Haar beschert. Spring Boot geht dieses Thema an, in dem es einen wohldefinierten Satz an Abhängigkeiten und deren Versionen definiert und diese Definition über bekannte Dependency- Management-Werkzeuge wie Maven oder Gradle anbietet. Im Falle von Maven geschieht dies über ein Parent-POM, das die Versionsnummern der unterstützten Abhängigkeiten im <properties />- und <dependencymanagement />-Block definiert. Um nun Abhängigkeiten zu konsumieren, kann man diese jeweils selbst definieren, allerdings ohne die Versionsnummern explizit anzugeben. Da in vielen Fällen aber gleich ganze Sätze an Abhängigkeiten benötigt werden zum Beispiel Spring Data JPA mit Hibernate bietet Boot so genannte Starter- POMs an, die für einen bestimmten Technologiebereich Abhängigkeitssätze definieren. Das eben bereits angesprochene Starter- POM spring-boot-starter-data-jpa deklariert Abhängigkeiten zu Spring Data JPA, Hibernate, dem Spring-ORM-Modul und dem Starter-POM für JDBC. Dies wiederum beinhaltet das Spring-JDBC-Modul und eine Abhängigkeit zum Tomcat Connection Pool. So bekommt man durch die Deklaration einer einzigen Abhängigkeit einen kompletten Satz an Dependencies in kompatiblen Versionen. Dadurch, dass die Versionen der individuellen Abhängigkeiten als Maven- bzw. Gradle-Properties definiert sind, ist es allerdings auch möglich, Versionen für bestimmte Dependencies manuell zu definieren und so im Falle eines wichtigen Bugfix-Releases die funktionierende Version zu beziehen. Versionsupgrades von Abhängigkeiten liegen also immer noch im Verantwortungsbereich des Entwicklerteams, können z. B. auf eine Spring-IO-Version standardisiert werden, um so das benötigte Maß an Konsistenz zwischen Applikationen herzustellen. Defaults in der Anwendungskonfiguration Kommen wir noch einmal zurück zum Beispiel Spring Data JPA. Durch die Deklaration des entsprechenden Starter-POMs können wie oben beschrieben auf einen Schlag die benötigten Abhängigkeiten (das JPA API Jar, Hibernate als Persistenzprovider und Spring Data JPA als Hilfsbibliothek) konsumiert werden. Nun ist es jedoch immer noch nötig, ein gewisses Konfigurationssetup zu definieren, um Spring die entsprechenden Komponenten instanziieren zu lassen. In unserem konkreten Fall wäre das Folgendes: Eine DataSource mit den entsprechenden Verbindungsdaten zum Datenbankserver Eine LocalContainerEntityManagerFactoryBean, um JPA zu initialisieren Einen JpaTransactionManager für das Transaktionsmanagement in den Spring Data JPA Repositories um das Auffinden von Spring Data Repository Interfaces und die Erzeugung der entsprechenden Spring Beans zu aktivieren Unabhängig davon, wie die Repository- Interfaces eigentlich aussehen, welche Daten persistiert werden, ist also ein gewisses Grundrauschen an Konfiguration notwendig, die sich die meisten Entwickler aus anderen Projekten oder Beispielen, die sie im Netz finden, zusammensuchen müssen. Spring Boot stellt nun mit seinem Autokonfigurationsmodul einen Mechanismus zur Verfügung, der dieses Vorgehen sehr stark vereinfacht. an einer Konfigurationsklasse inspiziert Boot den Classpath der Applikation und erzeugt eine wohldefinierte Menge von Default-Konfiguration, es sei denn, es sind für die zu registrierenden Komponenten bereits manuelle Bean-Definitionen vorhanden. In unserem Beispiel genügt also @ComponentScan class Application {... um die Spring-Data-JPA-Konfiguration wie oben beschrieben zu defaulten. Hierbei wird sehr stark damit gearbeitet, feststellen zu können, welche Bibliotheken im Applikations-Classpath vorhanden sind. Das Vorhandensein von H2 oder HSQLDB sorgt zum Beispiel für die automatische Registrierung Anzeige

6 Titelthema Spring IO Das erste offizielle Release der Spring-IO-Plattform ist für das erste Quartal 2014 geplant. einer In-Memory-DataSource über die Mechanismen, die Spring über den EmbeddedDatabaseBuilder bereitstellt. Dadurch, dass das Hibernate EntityManager JAR im Classpath liegt, wird eine LocalContainerEntityManagerFactory deklariert und ein JpaTransactionManager. Das Scannen nach Spring Data JPA Repositories wird vom Vorhandensein des Spring Data JPA JARs ausgelöst usw. Dieser Mechanismus ist eigentlich eine Umsetzung des bekannten Convention-Over-Configuration-Mechanismus. Das heißt, man schreibt nur die Konfiguration, die explizit von den Defaults abweicht. Um dies zu tun, gibt es zwei Möglichkeiten: Konfigurationsdetails, die sich sehr wahrscheinlich von Applikation zu Applikation unterscheiden werden, kann man über ein Properties-File namens application.properties im Classpath bzw. dem Ausführungsverzeichnis anpassen oder über JVM-Parameter definieren. Klassiker hierbei sind Informationen wie der JDBC-URL der Datenbank, Benutzername und Passwort usw. Um jedoch auf weitergehende, explizite Konfiguration eingehen zu können, registriert Boot die Default-Bean- Definitionen nur, wenn nicht bereits eine Bean-Defini- @ComponentScan class Application public DataSource datasource() { // Explizite Deklaration hier @ComponentScan class Application { public static void main(string... args) { SpringApplication.run(Application.class, args); tion des entsprechenden Typs vorhanden ist. Um zum Beispiel die DataSource komplett anders zu konfigurieren als im Default, genügt es, eine entsprechende Bean- Definition zu deklarieren (Listing 1). Für diese Datei konfiguriert Boot die gleichen Defaults wie oben beschrieben, nutzt aber die hier explizit deklarierte DataSource. Auf diese Weise zieht sich Boot für manuell konfigurierte Bean-Definitionen diskret zurück und nutzt diese transparent für seine weitere Arbeit. Vereinfachter Betrieb von Java-Applikationen Traditionell werden Java-Webanwendungen in einem Server betrieben. Dies kann sowohl ein einfacher Servlet Container wie Tomcat sein, aber auch ein größerer Application Server, der neben einer Servlet-Umgebung noch weitere Dienste zur Verfügung stellt. Theoretisch sieht das Nutzungsmodell dieser Server vor, mehrere Applikationen in eine Serverinstanz zu deployen, um Ressourcen wie Connection-Pools zentral verwalten zu können. In vielen Fällen wird heutzutage jedoch jeweils eine einzelne Applikation in eine einzelne Serverinstanz deployt. Dies ist vor allem der Fall, da das gemeinsame Deployment von Applikationen diese indirekt über die Infrastruktur aneinander koppelt. Muss der Server zum Beispiel für ein Upgrade heruntergefahren werden, betrifft das immer alle Applikationen, die in ihm deployt sind. Sorgt eine Applikation im Server für ein Speicherleck, betrifft das unter Umständen auch die anderen Applikationen. Ein alternativer Ansatz, der mehr und mehr Verbreitung findet, ist es, die benötigten Serverkomponenten mit der Applikation zu bündeln und auch mit ihr zu starten. Im Zusammenhang mit den oben beschriebenen Mechanismen zum Dependency Management und den entsprechenden Defaults bezüglich der Konfiguration bietet Spring Boot einen zweistufigen Mechanismus, um dieses Embedded-Server-Modell zu betreiben (Listing 2). Man kann eine Spring-Boot-basierte Applikation starten, indem man sich über den bereits beschriebenen Mechanismus zum Beispiel Tomcat oder Jetty in den Classpath holt und eine Java-Klasse mit einer main( )-Methode deklariert, die per statischem Aufruf Spring- Application die Konfigurationsklasse (hier ein und dieselbe Klasse) übergibt. Boot findet die Serverkomponenten sowie Spring MVC im Classpath, leitet daraus die Notwendigkeit des Serverstarts ab und sorgt selbstständig für das Hochfahren des Servers. Oft anzupassende Konfigurationswerte zum Beispiel der Serverport oder der Kontextpfad der Applikation können wie oben bereits beschrieben über die application.properties-datei oder JVM-Parameter überschrieben werden. Um die Applikation einfach starten zu können, ist es notwendig, ein JAR zu erzeugen, das alle Abhängigkeiten enthält. Hierzu kann ein Maven- bzw. Gradle- Plug-in verwendet werden. Bevorzugt man weiterhin das Deployment in einen Application Server, so genügt es, das Projekt als WAR-Projekt zu definieren. Das Spring-Boot-Maven- bzw. -Gradle-Plug-in sorgt dann beim Build automatisch dafür, dass neben der norma- 36 javamagazin

7 Spring IO Titelthema len WAR-Datei auch ein startbares WAR erzeugt wird. Zum Start der Applikation ruft man nach erfolgreichem Build einfach java -jar target/*.(jar war). Zur Entwicklungszeit in der IDE genügt natürlich das Starten der Klasse mit der oben beschriebenen main( )-Methode. Monitoring und Operations Ein oft genutztes Feature traditioneller Server ist die Möglichkeit, den Zustand der Applikation über Metriken beurteilen zu können bzw. sogar bestimmte Werte zur Rekonfiguration zur Laufzeit z. B. per JMX zu exportieren. Spring Boot stellt so genannte Actuator bereit, die mit der Applikation deployt werden können. Diese stellen dann ähnliche Funktionalität zur Verfügung, in dem sie Out of the Box ein paar HTTP-Ressourcen veröffentlichen, die vielseitige Informationen per JSON exponieren: /env die Properties der Ablaufumgebung (JVM- Argumente, System-Properties, die Systemumgebung) /health ein einfaches OK, wenn die Anwendung gestartet werden konnte /info spezielle Properties unter dem Schlüssel endpoints.info.$key; hier können z. B. Informationen wie die Applikationsversion einfach hinterlegt werden /metrics Basismetriken der Applikation (Speicherverbrauch, Counter der HTTP-Statuscodes usw.) /trace Informationen über die letzten 100 Anfragen an die Applikationen (HTTP-Request-URL, Header, Response usw.) /dump ein Threaddump der Applikation /beans eine Liste aller Spring Beans der Applikation Getting Started Guides Ein weiterer, lose mit Spring IO verbundener Aspekt der Plattform sind die komplett überarbeiteten Getting Start ed Guides, die auf zu finden sind. Die große Popularität des Spring Frameworks sorgte über die Jahre für eine Vielzahl verschiedenster Tutorials, die im Netz zu finden sind. Nachteil dieser Fülle ist, dass Entwickler, die heute nach Lösungen für ein bestimmtes Problem suchen, oft sehr alte und damit auch oft veraltete Informationen finden. Die Getting Started Guides sind aufgabenbasiert, d. h. es steht nicht primär die verwendete Technologie im Vordergrund, sondern ein bestimmtes Ziel wie zum Beispiel das Persistieren von Daten in eine relationale Datenbank, das Veröffentlichen von Daten als HTTP- Ressourcen usw. Die Beispiele sind in ungefähr zehn Minuten durchzuarbeiten, nutzen Spring Boot und erlauben dem Entwickler so, sich rasch in Spring und seine Ökosystemprojekte einzuarbeiten. Zeitplan und Ausblick Das erste offizielle Release der Spring-IO-Plattform ist für das erste Quartal 2014 geplant. Initial bestehen wird es aus einem wohldefinierten Set an zusammenarbeitenden Spring-Modulen und den entsprechenden Mechanismen, diese Module auf einfachste Weise zu konsumieren. Zusammen mit dem Kernframework in Version 4 bietet Spring eine zukunftsfähige Plattform für Java-basierte Unternehmensanwendungen im Jahre Oliver Gierke ist Teil des Spring-Data-Teams bei SpringSource, a division of VMware, und leitet dort das JPA-, MongoDB- und Core- Modul. Seit über sechs Jahren widmet er sich dem Entwickeln von Java-Enterprise-Applikationen, Open-Source-Projekten und ist Mitglied der JPA 2.1 Expert Group. Seine Arbeitsschwerpunkte liegen im Bereich Softwarearchitektur, Spring und Persistenztechnologien. Er ist regelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln. Links & Literatur [1] Anzeige Anzeige