aber es gibt in der Java-Community ein Bemühen, auch für diesen Bereich Standards zu schaffen, da Batchanwendungen in vielen Unternehmen das Rückgrat der Informationsverarbeitung sind und für Dateiverarbeitung, Massenverarbeitung oder zeitgesteuerte Hintergrundverarbeitung eingesetzt werden. Mit JSR 352 existiert jetzt ein Standard, welcher Batchverarbeitung im Umfeld von Java definiert. Der vorliegende Artikel stellt Ihnen die grundlegenden Konzepte vor.
Unter Batchverarbeitung versteht man im Allgemeinen eine Verarbeitung ohne Nutzerinteraktion. Auf diesem Gebiet tummeln sich jedoch schon bereits so etablierte Mitspieler wie Apache Camel oder Spring Integration. Eine neue Spezifikation ist notwendig, da JSR 352 eine andere Sicht auf Batchverarbeitung liefert.
Stellen Sie sich das Szenario einer satzorientierten Verarbeitung einer Datei vor. In dieser Datei finden sich gleichartige Sätze, welche auf gleiche oder zumindest vergleichbare Art behandelt werden sollen. Es wird immer nach gleichem Muster “lesen, verarbeiten, schreiben” vorgegangen. Diese Idee kommt der klassischen Stapelverarbeitung nahe.
Diese spezielle Sicht auf Batchverarbeitung als Stapelverarbeitung ist Grundlage für den JSR 352 und macht es möglich, einheitliche Lösungen für immer wiederkehrende Funktionalität (Querschnittsfunktionalität wie Transaktionsbehandlung, Wiederanlauf oder Nebenläufigkeit) zu realisieren.
Eine Verarbeitungskette (Job) kann sich in mehrere Einzelschritte aufteilen, im Sprachgebrauch der Spezifikation Step genannt. Er beschreibt die Steps, legt ihre Verarbeitungsreihenfolge fest und definiert Eigenschaften wie Wiederanlauffähigkeit.
In einem Step wird eine Menge an Items verarbeitet. Items können je nach Anwendungsfall Sätze einer Datei, Zeilen eines Excel-sheets, Sätze einer Datenbank oder andere gleichartige Größen der Programmlogik ein. Items werden nach dem oben beschriebenen Muster “lesen, verarbeiten, schreiben” behandelt.
Architektur
Laufzeitmodell
Ein Job kann mit einem Satz an benannten Parametern gestartet werden. Diese JobParameter können zu jedem Start des Jobs neu definiert werden. Ein Job mit einem festgelegten Parametersatz ist eine JobInstance.
Im Falle eines Abbruchs kann eine solche JobInstance nochmals gestartet werden. Daher muss zwischen den einzelnen Ausführungen einer JobInstance unterschieden werden. Die einzelne Ausführung heißt JobExecution.
Die Zentrale zur Verwaltung von Jobs ist der JobOperator. Dort werden Jobs gestartet und ggf. abgebrochen und es können alle Informationen über aktuell verfügbare Jobs, JobInstances und JobExecutions abgerufen werden.
Alle Informationen über Jobs müssen gesichert werden. In dieser Sicherung finden sich die Informationen über die tatsächlichen Jobausführungen, aber auch Informationen zum Wiederanlauf. Diese Aufgabe fällt dem JobRepository zu. Über die Struktur und die genauen Eigenschaften macht die Spezifikation keine Aussagen. Es wird nur die Existenz eines JobRepositories vorgegeben.
Die Ausführung und Koordination der Jobs wird durch die Batchlaufzeitumgebung (Batch Runtime) übernommen.
Einen Überblick über die Architektur liefert Abbildung 1. Dort werden insbesondere die logischen Beziehungen der einzelnen Komponenten zum JobRepository beschrieben.
Abbildung 1: Grundlegende Architektur eines Batchjobs (Quelle: http://jcp.org/en/jsr/detail?id=352)
Verarbeitungsschritte – Steps
Abbildung 2 illustriert das oben genannte Verarbeitungsmuster “lesen, verarbeiten, schreiben”. Items werden einzeln eingelesen (ItemReader) und verarbeitet (ItemProzessor). Anschließend werden die Items zu Gruppen (Chunks) zusammengefasst. Diese Gruppen werden schlussendlich durch den ItemWriter herausgeschrieben. Eine solche Verarbeitungssequenz ist ein Step.
Neben standardmäßigen Kriterien zur Bildung eines Chunks, wie Anzahl an Items oder Zeitspanne bis zum Abschluss der Verarbeitung, können auch Algorithmen mit eigenen Kriterien definiert werden.
Der Zusammenhang zwischen Chunks und Transaktionen ist sehr griffig: Transaktionen richten sich nach Chunks. Wird ein neuer Chunk eröffnet, so wird auch eine Transaktion gestartet. Mit der abschließenden Verarbeitung des Chunks im Schreibvorgang wird die Transaktion geschlossen.
Diese Form der Verarbeitung heißt Chunk-orientierte Verarbeitung und ist die reguläre Verarbeitungslogik von Steps.
Abbildung 2: Verarbeitung innerhalb eines Chunk-orientierten Steps
Um Aufgaben wie Initialisierungen oder abschließende Aufräumarbeiten auszuführen, welche nicht in das Korsett einer Chunk-Orientierung passen, bietet die Spezifikation das Batchlet an.
Ein Batchlet repräsentiert eine Aufgabe und kann gestartet und ggf. gestoppt werden. Es werden keinerlei Annahmen über innere Struktur und Ablauf gemacht. Für Batchlets gibt es keine transaktionale Unterstützung der Batch Runtime.
Ein Step beinhaltet entweder ein Batchlet oder setzt eine Chunk-orientierte Verarbeitung um.
Nach der Einführung in die grundlegenden Konzepte der JEE-Batchverarbeitung werden die Themen in den folgenden Artikeln vertieft.
