Download: "Erratum: Die Zukunft des Frühlings von

Java Magazin 1.2014 automated
Elasticsearch
on-demand
OSGi
Neo4j-Tutorial
Application Client Container
magazin
Java • Architekturen • Web • Agile
• Web service pushing your
CI process forward
• Save up to 90% of your
testing time & budget
• No modification required
• CI server Plug-Ins
www.javamagazin.de
Elasticsearch
Java EE und der ACC
Suche mit anderen Augen 69
Der unbekannte Dritte 45
ngs
!
ier im Heft
h
s
fo
In
e
All
22
O
I
g
Sprin
li
Die Zukunft des Früh
FX Traits
Find bugs before your users do! Try now!
1.2014
Java ME 8
30 days free trial!
Visit our website or call us
www.testobject.com
+49 (0) 3302/559375
Österreich € 10,80 Schweiz sFr 19,50 Luxemburg € 11,15
Spring IO
easy
Deutschland € 9,80
Spring mit
neuem Look und
neuem Feel? 32
IDE-Integration
mit der Spring
Tool Suite 38
Spring Boot:
New Kid on
the Stack 42
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
© iStockphoto.com/_Rike_
Mobile App Testing
in the Cloud
Java Mag
Neo4j-Tutorial: Graphdatenbanken zum Anfassen 82
Titelthema Spring IO
Was es mit der neuen Plattform auf sich hat
Zukunft
Die
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.
32
javamagazin 1 | 2014
© iStockphoto.com/_Rike_
von Oliver Gierke
www.JAXenter.de
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 907 – @Transactional) 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
www.JAXenter.de
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 Founda­
tion. 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 LegacyTechnologien wie SOAP (durch Spring Web Services)
javamagazin 1 | 2014
33
Titelthema Spring IO
tur 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 2012. 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 SpringApplikationen an:
aber auch unentdecktere Aspekte wie Hypermedia im
Bereich REST Web Services (durch Spring HATEOAS).
1.Vereinfachtes Dependency Management
2.Automatische Defaults in der Anwendungskonfiguration
3.Vereinfachtes Deployment und Betrieb von JavaApplikationen
IO Execution
Vereinfachtes Dependency Management
Auf den Bereich der Foundation setzt nun der ExecutionBereich 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 Projektstruk-
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 DeploymentPlattform 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.
Abb. 1: Spring IO Platform Stack
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.
http://bit.ly/1dkmjG1
34
javamagazin 1 | 2014
www.JAXenter.de
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 DependencyManagement-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 StarterPOMs an, die für einen bestimmten Technologiebereich Abhängigkeitssätze definieren.
Das eben bereits angesprochene StarterPOM 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.
www.JAXenter.de
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
•Ein @EnableJpaRepositories, um das
Auffinden von Spring Data Repository
Interfaces und die Erzeugung der entsprechenden Spring Beans zu aktivieren
Unabhängig davon, wie die RepositoryInterfaces 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. Durch @EnableAutoConfiguration 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 diese
Konfigurationsklasse
@Configuration
@EnableAutoConfiguration
@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
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-BeanDefinitionen nur, wenn nicht bereits eine Bean-Defini-
Listing 1
@Configuration
@EnableAutoConfiguration
@ComponentScan
class Application {
@Bean
public DataSource dataSource() {
// Explizite Deklaration hier
}
}
Listing 2
@Configuration
@EnableAutoConfiguration
@ComponentScan
class Application {
public static void main(String... args) {
SpringApplication.run(Application.class, args);
}
}
36
javamagazin 1 | 2014
tion des entsprechenden Typs vorhanden ist. Um zum
Beispiel die DataSource komplett anders zu konfigurieren als im Default, genügt es, eine entsprechende BeanDefinition 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 SpringApplication 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. GradlePlug-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-
www.JAXenter.de
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 (JVMArgumente, 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
ü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 HTTPRessourcen 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 2014.
Oliver Gierke ist Teil des Spring-Data-Teams bei SpringSource, a
division of VMware, und leitet dort das JPA-, MongoDB- und CoreModul. 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.
Getting Started Guides
Ein weiterer, lose mit Spring IO verbundener Aspekt
der Plattform sind die komplett überarbeiteten Getting
Start­ed Guides, die auf http://spring.io zu finden sind.
Die große Popularität des Spring Frameworks sorgte
Links & Literatur
[1] http://jaxenter.de/artikel/Spring-XD-fuer-Big-Data
Anzeige
Anzeige