document

JAVA Mag
Micro Batch Services powered by Spring Boot 58
10.2014
magazin
Java • Architekturen • Web • Agile
www.javamagazin.de
7
Semantic Versioning
Gradle 2.0
Sinn für die Versionsnummer 12
Die neuen Features im Überblick 14
Java EE
Ab in den siebten Himmel
Best Practices: WildFly-8Installationen verwalten
Buchtipp zu Java EE 7
r
ü
f
k
c
u
r
onderd
34
40
47
S Multi-Browser-Tab-Support
e
d
.
c
i
r
t
n
e
c
e
50
© iStockphoto.com/Kngkyle2
www.cod
Proxy oder Delegator – das ist hier die
Frage 18
infos
Programm
9!
ab Seite 1
Continuous Delivery
für PaaS: Pipeline automatisieren 72
Architekturvalidierung:
Auf die inneren Werte
kommt es an 96
© iStockphoto.com/liangpv
Sonderdruck
Agile
Micro Batch Services powered by Spring Boot
Batcharchitektur
in the Enterprise
Immer mehr Unternehmen setzen auf Batchverarbeitung in Java – nur wie macht man es
richtig? In diesem Artikel stellen wir die unserer Erfahrung nach optimale Architektur für
Batch Services im Enterprise-Umfeld zunächst frameworkneutral vor: verteilte Umgebung,
Container, Kommunikation über HTTP, fertig. Vielfach kundenerprobt. Und doch – ganz problemfrei und schnell geht es nicht immer. Aufwände fließen in die Entwicklung eines eigenen Meta-Batch-Frameworks, der Umgang mit den Application Servern ist nicht immer ganz
einfach, und schnell entstehen Batchmonolithen mit Unmengen von Jobs – ein Horror für
Updates und Testing. Wie kann man diese Aufwände umgehen? Dieser Artikel zeigt, wie ein
eigener Spring Boot Starter dafür sorgt, dass man nur noch Jobs schreiben muss und alles
andere geregelt ist.
von Tobias Flohre und Dennis Schulte
Es gibt viele verschiedene Wege, Batch Jobs zu schreiben
und zu betreiben, und dieser Artikel hat nicht zum Ziel
diese alle aufzulisten – dafür wäre auch gar kein Platz.
Hier soll es um den unserer Erfahrung nach optimalen
Weg im Enterprise-Umfeld gehen. Und dann wollen wir
noch aufzeigen, was Microservices damit zu tun haben.
Bei der Einführung von Java Batch im Unternehmen
müssen drei Fragen beantwortet werden:
2
javamagazin 10 | 2014
1.Soll ein Framework verwendet werden? Wenn ja,
welches?
2.Wie sollen die Batch Jobs betrieben werden?
3.Wie werden die Batch Jobs ins Unternehmen eingebunden? Wer startet sie?
1. Soll ein Framework verwendet werden? Wenn ja,
welches?
Es gibt gewisse Features, die man bei der Batchentwicklung immer benötigt, dazu gehören automatisches
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck
Agile
Transaktionsmanagement, persistente Jobmetadaten
und Fehlerhandling, und häufig möchte man auch Restart-Fähigkeit und Skalierungsmöglichkeiten haben.
Ein unternehmensweit einheitliches Programmiermodell für Jobs hat ebenfalls viele Vorteile. Ein etabliertes
Framework zu verwenden, ergibt also Sinn. Wir haben
sehr gute Erfahrungen mit Spring Batch [1] gemacht,
aber wir sind auch nicht darauf fixiert – der Batchstandard JSR 352 [2] beinhaltet die oben genannten Features, und andere Implementierungen als Spring Batch
können ebenfalls sinnvoll sein [3].
2. Wie sollen die Batch Jobs betrieben werden?
Weder der JSR 352 noch Spring Batch geben vor, wie
Jobs betrieben werden, auch wenn einige JSR-352-Implementierungen direkt an Java-EE-Container gebunden sind. Prinzipiell hat man also die Wahl, ob man
für jeden Batchlauf eine eigene JVM startet, ob man die
Jobs in einen Java EE Application Server deployt oder
ob ein Servlet-Container ausreicht. Wir empfehlen aus
folgenden Gründen den Betrieb in einem Servlet Container/Application Server:
•HTTP ist ein etabliertes Protokoll zur Kommunikation zwischen Anwendungen auch in polyglotten Umgebungen, das auch gut abgesichert werden kann.
•Ein kontinuierlich laufender Batchserver ermöglicht
ein Fail Fast. Bereits beim Hochfahren werden umgebungsabhängige Konfigurationen und Verbindungen
zu Fremdsystemen geprüft, sodass beim tatsächlichen
Jobstart weniger Fehlerquellen vorhanden sind.
•Monitoring für Servlet Container ist etabliert – sei es
über HTTP, JMX oder als Support für einen konkreten Application Server.
•Das Speichermanagement ist mit kontinuierlich laufenden Anwendungen einfacher. Sollten JVMs beliebig gestartet und gestoppt werden, kann es passieren,
dass das Betriebssystem nicht so viel Speicher zur
Verfügung stellen kann wie gerade benötigt wird.
Dazu kommen in vielen Unternehmen hausweite Vorgaben für den Betrieb von Java-Anwendungen, die
diesen auf bestimmte lizenzierte Systeme mit EnterpriseSupport einschränken. WebSphere-, JBoss-, GlassFish-,
WebLogic- und Tomcat-Server sind hier oft genutzte
Kandidaten und funktionieren mit unserem Ansatz.
3. Wie werden die Batch Jobs ins Unternehmen
eingebunden? Wer startet sie?
Die Jobsteuerung und die konkrete Jobausführung sollten immer entkoppelt sein (Abb. 1). Dabei empfehlen
wir ein REST-like HTTP-API auf der Seite der Batchanwendung, das vier Funktionen hat:
•Job starten
•Status des Jobs abfragen
•Job stoppen
•Protokoll des Joblaufs abholen
www.JAXenter.de
Abb. 1: Jobsteuerung und -ausführung
Für die Jobsteuerung gibt es in den meisten größeren
Unternehmen, die auch noch einen Mainframe betreiben, eine zentrale Stelle, über die alle Jobs eingeplant
werden. Hier stellt sich die Frage der Anbindung unseres
Batchservers. Sollte es so einen Scheduler noch nicht geben, ist die Wahl der Mittel frei – von einem einfachen
Cron-Job bis zur Einbindung in ein Workflowsystem ist
alles möglich. Wie auch immer der Client aufgebaut ist,
bei der Kommunikation mit unserem Batchserver sollte
er diesen einfachen Algorithmus verwenden:
•den Job starten,
•dann in regelmäßigen Intervallen prüfen, ob der Job
beendet wurde,
•und sobald das der Fall ist, das Jobprotokoll auslesen
und zurückgeben.
Wir sind sehr für einfache Lösungen, und da bietet es
sich an, diese Logik in ein Skript zu verpacken. Hier
kann dann auch direkt ein Shutdown Hook eingebaut
werden, der den Job stoppt, falls der Operator das Skript
beendet, sodass ein konsistenter Stand gewährleistet
werden kann. Beim Ausführungsort und der gewählten
Skriptsprache ist man frei – viele unserer Kunden betreiben ihr Jobsteuerungssystem bzw. Scheduler auf dem
Mainframe, und hier bietet sich beispielsweise REXX
an. In Unix-basierten Umgebungen führt ein einfaches
Shellskript natürlich auch zum Ziel.
Herausforderungen
So weit, so gut – dieses Konzept funktioniert so schon
in vielen Unternehmen, und doch gibt es einige Herausforderungen:
Es entstehen Monolithen – Nach Conways Gesetz [4]
spiegelt sich in erstellten Systemen die Kommunikationsstruktur des Unternehmens. Häufig äußert sich das
dadurch, dass es eine Batchanwendung pro Abteilung
gibt, auf der sich mit der Zeit immer mehr Jobs einfinden. Jede Veränderung der Anwendung wird dadurch
erschwert, dass potenziell alle anderen Jobs betroffen
sein könnten und deshalb nachgetestet werden müssen.
Und auch wenn man viel automatisiert testen kann –
gerade im Batchbereich gibt es immer wieder Konstel-
© Software & Support Media GmbH
javamagazin 10 | 2014
3
Sonderdruck
Agile
lationen, die automatisierte Tests erschweren, vor allem
wenn es darum geht, produktionsnahe Daten und Datenmengen zu verarbeiten.
Die Handhabung von Containern ist unnötig komplex – Wie Eberhard Wolff in seinem Artikel über den
Tod des Application Servers [5] schreibt, gibt es einige
Argumente gegen eine Separation von Anwendung und
Container, die auch hier greifen:
•Ein Parallelbetrieb von mehreren Batch- und Onlineanwendungen auf einem Application Server ist bezüglich der Ressourcen gefährlich und wird deshalb
allgemein vermieden. Viele Features eines Application
Servers bleiben so zu Recht ungenutzt.
•Der Application Server hängt durch anwendungsspezifische Ressourcen davon ab, die Anwendung
wiederum vom Application Server – diese zyklische
Abhängigkeit indiziert eine enge Kopplung. In der
täglichen Arbeit behindert uns diese Abhängigkeit
durch komplexes Aufsetzen von (Entwicklungs-)
Umgebungen für unterschiedliche Versionen unserer
Software.
Listing 1
<?xml version="1.0" encoding="UTF-8"?>
<project ...>
<modelVersion>4.0.0</modelVersion>
<groupId>de.codecentric.batch</groupId>
<artifactId>batch-boot-simple</artifactId>
<version>0.0.1-SNAPSHOT</version>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
javamagazin 10 | 2014
Wir streben also eine Lösung der skizzierten Herausforderungen an, die folgende Ziele unterstützt:
1.Unsere favorisierte Architektur/Unternehmensintegration soll out of the box unterstützt werden.
2.Die Verwendung sollte extrem einfach sein. Außer
dem Schreiben von Jobs sollte alles geregelt sein.
Durch die einfache Verwendung ist es dann auch
kein Problem, für jeden Job eine eigene Anwendung
zu haben.
3.Die Lösung sollte allgemein benötigte Funktionalität, die wir sonst bei jedem Kunden neu entwickelt
haben, automatisch beinhalten, um die Aufwände
für das Batch-Meta-Framework gering zu halten.
Micro Batch Services
<dependencies>
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-starter-batch-web</artifactId>
<version>1.0.0.RELEASE</version>
</dependency>
</dependencies>
4
Die Lösung der Probleme
Wie kann sie aussehen?
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.0.2.RELEASE</version>
</parent>
</project>
Ein Batch-Meta-Framework wird benötigt – Die Verwendung von Spring Batch oder einer anderen JSR352-Implementierung allein reicht nicht. Ein Scheduling
muss immer angebunden werden, außerdem gibt es
meistens noch weitere unternehmensweit einheitliche
Vorgaben, die jeder Batch Job umsetzen muss, wie beispielsweise ein einheitliches Jobprotokoll, Logfiles pro
Joblauf etc. Auch für das Monitoring muss man noch
aktiv werden. Dieses Batch-Meta-Framework muss
ebenfalls gepflegt werden, den Aufwand darf man nicht
unterschätzen. Der Umgang mit diesen Herausforderungen bestimmt sehr stark den Gesamtaufwand, den wir
im Batchbereich im Unternehmen haben.
Die grundsätzliche Basis für die Lösung ist, wie der Titel schon vermuten lässt, eine Microservices-Architektur [6]. Ein Batch Job passt optimal in dieses Paradigma
– es handelt sich um ein fachlich eigenständiges Modul,
das sich leicht austauschen lässt. Er hat eine klar definierte REST-Schnittstelle (s. o.), und ein GUI wird in
diesem Fall nicht benötigt. Durch die totale Prozessisolation, die Nutzung eines eigenen Heaps, sind GC-Probleme oder sonstige Speicher-Leaks durch Seiteneffekte
ausgeschlossen, und auch sonst kann von allen Vorteilen dieses Konzepts profitiert werden.
Wir wollen also tatsächlich möglichst immer nur einen
Job in einer Anwendung betreiben. Das ermöglicht den
parallelen Betrieb unterschiedlicher Versionen einer bestimmten Batch- oder fachlichen Bibliothek. Natürlich
wird es immer Batch Jobs geben, die sich fachlich so nahe
stehen, dass sie einen Großteil ihres Codes teilen können.
Hier muss man nun mit gesundem Menschenverstand arbeiten. Ergibt es Sinn, diese doch in einer gemeinsamen
Anwendung zu betreiben? Löst man den geteilten Code
heraus in eine Bibliothek, die von beiden verwendet wird?
Wir kennen viele Beispiele, in denen das „Don’t Repeat
Yourself“-Prinzip übertrieben wurde und in unverständlichen, generischen Alleskönnerkomponenten mündete.
Manchmal ist es auch einfach okay, sich zu wiederholen.
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck
Agile
Im Bereich Migration von Legacy-Anwendungen, in
dem Java Batch stark im Kommen ist – viele alte Cobolbatches werden aktuell auf Java umgestellt – kann man
nun schrittweise vorgehen und die alten Batches Anwendung für Anwendung auf eine neue und moderne
Plattform stellen.
Spring Boot
Nur wie setzen wir das um? Spring Boot hat sich als
gute Basis unserer Arbeit erwiesen. Die jetzt geschaffene
Lösung bietet einen maßgeschneiderten Batchserver, benötigte dabei aber nur wenig Aufwand.
Spring Boot ist ein relativ neues Projekt im Spring-Ökosystem, das auf den anderen Frameworks aufsetzt [7]. Für
unterschiedliche Technologien gibt es Spring Boot Starter
POMs, die man per Maven oder Gradle einbinden kann,
und dann wird über Auto-Configuration der ApplicationContext der Anwendung automatisch um entsprechende Konfigurationen erweitert. Bei Einbindung von
spring-boot-starter-web wird beispielsweise Spring MVC
passend aufgesetzt und ein Embedded Tomcat gestartet,
sodass ein Deployment in einem Servlet Container nicht
mehr notwendig ist. Eine Einführung in dieses Projekt
gab es bereits im Java Magazin 1.2014 [8].
spring-boot-starter-batch-web
Unsere Lösung besteht aus einem eigenen Spring Boot
Starter [9], der wiederum diese vier Standard-Boot-Starter einbindet:
•spring-boot-starter-batch konfiguriert die Batchinfrastruktur.
•spring-boot-starter-web erzeugt die Webinfrastruktur, sodass wir einfach Web-Endpoints erstellen können.
•spring-boot-starter-jdbc sorgt für eine gepoolte, konfigurierbare JDBC DataSource.
•spring-boot-starter-actuator bietet diverse Monitoring- und Operationswerkzeuge.
Alle Konfigurationsmöglichkeiten dieser vier Starter
können wie in der Spring-Boot-Referenz beschrieben
genutzt werden.
In spring-boot-starter-batch-web fügen wir die Features hinzu, die uns jetzt noch zur optimalen Lösung
fehlen. Wenn Sie wollen, öffnen Sie einfach Ihre favorisierte Entwicklungsumgebung, und führen Sie die folgenden Schritte mit uns durch. Der Weg zum fertigen
Batchserver inklusive Job benötigt nur wenige Minuten.
2.Als Parent wird spring-boot-starter-parent eingetragen. Dieser bringt Dependency-Management und
zueinander passende Versionen von Abhängigkeiten
mit sich. In vielen Unternehmen existieren eigene
Parents, sollten diese wirklich unbedingt benötigt
werden, so kann Spring Boot auch ohne springboot-starter-parent funktionieren [10].
3.Das spring-boot-maven-plugin wird hinzugefügt. Es
sorgt dafür, dass durch ein mvn package ein einzelnes ausführbares Jar erzeugt wird, das alle benötigten Libraries als Jars enthält, auch Fat Jar genannt.
Logging
Damit die Log-File-Separation funktioniert, wird eine
logback.xml im Root des Klassenpfads (also im MavenProjekt unter src/main/resources) benötigt, die unsere
Logging-Basiskonfiguration einbindet (Listing 2). Hier
können auch weitere Logging-Konfigurationen vorgenommen werden.
Datenbankanbindung
Im Regelfall möchte man die Spring-Batch-Metadaten
in einer Datenbank halten, damit sie auch noch auswertbar sind, wenn der Batchserver nicht mehr läuft. Zur
Erstellung dieser Tabellen bietet Spring Batch Skripte
für die unterschiedlichsten relationalen Datenbanken
an. Die Verbindungsdaten werden der Anwendung als
Properties mitgegeben. Dafür kann bei Spring Boot eine
application.properties-Datei im Root des Klassenpfads
angelegt werden (also wiederum unter src/main/resources), in die dann die entsprechenden Einträge eingesetzt
werden können (Listing 3). Werden keine Verbindungsdaten angegeben, wird automatisch eine In-MemoryDatenbank genutzt.
Jobs
Spring Batch unterstützt verschiedene Formate für die
Konfiguration von Jobs, die drei wichtigsten sind dabei XML, JavaConfig und JSR 352 Style. Wir werden in
diesem Artikel den Job in XML konfigurieren, da dieser
Ansatz zurzeit noch am bekanntesten ist. Dabei nutzen
Listing 2
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<include resource="logback-batch-base.xml" />
</configuration>
Erstellung des Maven-Projekts
Wir erstellen ein Standard-Maven-Projekt, Unterstützung dafür gibt es in jeder IDE. Listing 1 zeigt die benötigte Maven-POM. Dabei gibt es drei Besonderheiten:
1.Als Dependency wird unser spring-boot-starterbatch-web-Projekt eingetragen. Das ist wenig überraschend.
www.JAXenter.de
Listing 3
spring.datasource.url=jdbc:hsqldb:hsql://localhost/
spring.datasource.username=sa
spring.datasource.password=
spring.datasource.driverClassName=org.hsqldb.jdbcDriver
© Software & Support Media GmbH
javamagazin 10 | 2014
5
Sonderdruck
Agile
wir einen ItemReader, der hart kodierte Werte zurückgibt, und einen ItemWriter, der sie loggt. Die Implementierungen und weiteren Konfigurationsstile finden sich
unter [9].
Bei der Konfiguration in XML (Listing 4) muss die
Datei im Klassenpfad unter META-INF/spring/batch/
jobs platziert werden, damit sie automatisch gefunden
wird. Dieser Pfad kann mithilfe der Property batch.config.path.xml überschrieben werden.
Spring-Boot-Startklasse
Als Entry Point in die Anwendung dient eine Klasse mit
einer main-Methode (Listing 5). In einer IDE kann diese
Listing 4
<?xml version="1.0" encoding="UTF-8"?>
<beans ...>
<bean id="reader" class="de.codecentric.DummyItemReader"/>
<bean id="writer" class="de.codecentric.LogItemWriter"/>
<batch:job id="flatfileJob">
<batch:step id="step">
<batch:tasklet>
<batch:chunk reader="reader" writer="writer" commit-interval="3" />
</batch:tasklet>
</batch:step>
</batch:job>
</beans>
Listing 5
Listing 6
$ curl --data '' localhost:8080/batch/operations/jobs/{jobname}
$ curl localhost:8080/batch/operations/jobs/executions/{executionId}
$ curl localhost:8080/batch/operations/jobs/executions/{executionId}/log
$ curl -X DELETE localhost:8080/batch/operations/jobs/executions/{executionId}
Nun kann das Projekt mit einem mvn package gebaut
werden. Das dabei entstandene .jar-File kann mittels
java –jar <filename>.jar gestartet werden, und schon
haben wir einen laufenden Batchserver, auf dem unsere
konfigurierten Jobs deployt sind.
Mithilfe eines Operations HTTP Endpoints können
Jobs gestartet und gestoppt werden, außerdem kann auf
den BatchStatus des Jobs gepollt werden, um mitzubekommen, wenn er beendet wird, und das Logfile für den
Joblauf kann heruntergeladen werden. Listing 6 zeigt
die dazugehörigen curl-Befehle.
Ein Monitoring-HTTP-Endpoint liefert Informationen über deployte Jobs, über laufende Jobs und Detailinformationen zu jedem Joblauf (Listing 7).
Zusätzlich dazu ist das Spring-Boot-Actuator-Projekt
automatisch mit eingebunden, sodass dessen Endpoints
genutzt werden können. Eine komplette Auflistung findet sich unter [11]. Es sind viele interessante darunter,
beispielsweise kann ein Thread-Dump der Anwendung
über http eingesehen werden, diverse Metriken werden
geführt, und ein Health-Check der Anwendung ist darüber ebenfalls einfach möglich.
Spring Boots Nutzung eines eingebetteten Servlet
Containers zusammen mit unseren batchspezifischen
automatisch konfigurierten Features ergibt einen kleinen, aber feinen Batchserver mit genau den Funktionen,
die wir benötigen, und der mit einfachen Java-Mitteln
gestartet werden kann. Weitere Batchfeatures sind in
Planung.
Verteilte XA-Transaktionen sind mit dem eingebetteten
Tomcat nicht out of the box möglich. Da sie aus Performancegründen zu vermeiden sind und viele der neueren
Data-Storing-Technologien XA-Transaktionen sowieso
nicht unterstützen, ist dieser Nachteil gegenüber einem
Java-EE-Server vielleicht nicht so relevant. Für Transaktionen über eine JMS- und eine Datenbankressource
gibt es das Best Effort Pattern. Bei zwei Datenbanken
kann eventuell das Shared Resource Pattern Anwendung finden [12]. Wenn das auch nicht möglich ist, kann
entweder teilweise auf Transaktionalität verzichtet oder
eine eigenständige JTA-Implementierung wie Atomikos
verwendet werden.
Wie schreibt man eine eigene SpringBoot-Erweiterung?
Listing 7
$ curl localhost:8080/batch/monitoring/jobs
$ curl localhost:8080/batch/monitoring/jobs/runningexecutions
$ curl localhost:8080/batch/monitoring/jobs/runningexecutions/{jobName}
$ curl localhost:8080/batch/monitoring/jobs/executions/{executionId}
javamagazin 10 | 2014
Der Batchserver und seine Features
Was geht nicht?
@Configuration
@EnableAutoConfiguration
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
6
Klasse direkt gestartet werden, um die komplette Anwendung hochzufahren.
Das Schreiben einer eigenen Erweiterung ist zwar einfach,
aber detailliert nicht in wenigen Sätzen zu erklären, deswegen wird es dazu einen eigenen Artikel im nächsten Java
Magazin geben.
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck
Agile
Die Batchentwicklung in Java ist im Kommen. Wenn man die
grundsätzlichen Architekturprinzipien aus diesem Artikel befolgt,
ist man auf jeden Fall schon auf dem richtigen Weg.
Betrieb: natürlich, ganz ohne Application Server
Der Build liefert uns also ein ausführbares Jar – schauen wir uns nun die letzten Meter auf dem Weg in die
Produktion an. Die natürlichste Art, auf Unix-Systemen
Anwendungen zu installieren, ist die Nutzung von Paketformaten wie RPM und deb. Außer dem ausführbaren Jar benötigen wir im Paket noch ein Init-Skript, mit
dem unsere Batchanwendung gestartet werden kann, für
ein Beispiel siehe [13]. Es kann einfach aufgerufen werden, ohne dass man die Spezifika des jeweiligen Service
kennen muss, und es umfasst meist ein Start-, Stop-, Restart- und Statuskommando.
Ein RPM kann relativ einfach mit Maven erzeugt
werden (siehe dazu die Beispielkonfiguration des rpmmaven-plugin unter [14]). Ein RPM fasst die zu installierenden Artefakte und das so genannte Spec-File zu
einem Paket mit der Endung .rpm zusammen. Im SpecFile steht dann, was zum Installations- und zum Deinstallationszeitpunkt geschehen soll, also das Kopieren
der Artefakte, Rechtevergabe etc.
Zur letztendlichen Durchführung der Installation des
RPMs wird der jeweilige Paketverwalter der verwendeten Linux-Distribution wie z. B. zypper bei SUSE, APT
bei Ubuntu oder auch Yum bei Red Hat verwendet.
Eventuell vorhandene umgebungsabhängige Properties
werden zum Installationszeitpunkt aus einem SCM geladen. Zur weitergehenden Automatisierung der Provisionierung können Konfigurationsmanagementwerkzeuge
wie z. B. Puppet [15], Chef [16] oder Ansible [17] eingesetzt werden. Die Verwendung eines standardisierten
und dem Systemadministrator bekannten Werkzeugs
erleichtert die Übergabe in Produktion. Im Problemfall
kann sehr einfach eine alte Version der Anwendung
über den Paketverwalter wiederhergestellt werden.
Tobias Flohre arbeitet als Senior-Softwareentwickler bei der codecentric AG. Seine Schwerpunkte sind Java-Enterprise-Anwendungen und Architekturen mit JEE/Spring, häufig mit Fokus auf Spring
Batch. Er spricht regelmäßig auf Konferenzen und bloggt auf blog.
codecentric.de.
[email protected].
Dennis Schulte ist seit 2009 als Senior IT Consultant bei der codecentric AG tätig. Er unterstützt seine Kunden insbesondere im Bereich Enterprise-Architekturen und der Optimierung von IT-Prozessen.
Aufgrund seiner langjährigen Erfahrung als Architekt und Entwickler
verfügt er über ein umfassendes Wissen im Bereich Java EE und
Open-Source-Technologien und hier insbesondere im Umfeld Spring Batch und
Massendatenverarbeitung. Seine Projektschwerpunkte liegen in der Architekturberatung und der Durchführung von Projekten im Versicherungsumfeld.
Links & Literatur
[1] http://projects.spring.io/spring-batch/
[2] https://jcp.org/en/jsr/detail?id=352
[3] http://bit.ly/1p6fNXn
[4] http://de.wikipedia.org/wiki/Gesetz_von_Conway
[5] Wolff, Eberhard: „Der Tod der Java Application Server“, in Java Magazin
7.2014
[6] Wolff, Eberhard: „Microservices“, in Java Magazin 8.2014
[7] http://projects.spring.io/spring-boot/
[8] Wolff, Eberhard: „Spring Boot“, in Java Magazin 1.2014
Fazit
Die Batchentwicklung in Java ist im Kommen. Wenn
man die grundsätzlichen Architekturprinzipien vom Anfang des Artikels befolgt, ist man auf jeden Fall schon
auf dem richtigen Weg.
Die dann im Folgenden beschriebene Verwendung
von Spring Boot bietet ein einfaches Programmier- und
Betriebsmodell, in dem alle wichtigen Funktionalitäten
bereits implementiert sind: HTTP Endpoints für das
Starten, Stoppen und Überwachen von Jobs sowie für
diverse Monitoringfunktionen vom Thread-Dump bis
zu Joblaufinformationen. Dieser Spring Boot Starter ist
dabei kein Spielprojekt – er ist bereits in Produktion im
Einsatz.
www.JAXenter.de
Die einfache Projekterzeugung und der unkomplizierte Betrieb mit Spring Boot ermöglicht dabei die Limitierung auf einen Job pro Anwendung – Micro Batch
Services.
[9] https://github.com/codecentric/spring-boot-starter-batch-web
[10] http://stackoverflow.com/questions/20731158/maven-module-usingspring-boot
[11] http://bit.ly/WB3zjc
[12] C
ogoluegnes, Arnaud; Templier, Thierry; Gregory, Gary; Bazoud, Olivier:
„Spring Batch in Action“, Manning
[13] https://github.com/codecentric/spring-boot-starter-batch-web/wiki/
Initscript-Template
[14] https://github.com/codecentric/spring-boot-starter-batch-web/wiki/
RPM
[15] http://puppetlabs.com/
[16] http://www.getchef.com/
[17] http://www.ansible.com/home
© Software & Support Media GmbH
javamagazin 10 | 2014
7
codecentric AG
Kölner Landstraße 11
40591 Düsseldorf
Tel: +49 (0) 211.9941410
Fax: +49 (0) 211.9941444
E-Mail: [email protected]
www.codecentric.de
blog.codecentric.de