Implementierungen des Standards
Die Spezifikation JSR 352 beinhaltet wenige Abhängigkeiten zur Infrastruktur, auf der sie umgesetzt wird. Insbesondere finden sich dort keine Abhängigkeiten zu JEE. Es werden keine Anforderungen an Persistenzverfahren, Transaktionsverarbeitung oder Threadmanagement gestellt. Obwohl die Spezifikation Teil des JEE-Standards ist, besitzt sie keinerlei Abhängigkeit zu weiteren JEE-Spezifikationen.
Der Standard verlangt nicht einmal eine allgemeingültige Unterstützung von Dependency Injection und gibt auch kein bestimmtes Konzept wie CDI oder Spring DI vor. Es werden lediglich einige wenige Anforderungen an die Unterstützung von Dependency Injection gestellt, wie die Möglichkeit, Kontexte zu injizieren oder @BatchProperty zu unterstützen.
Die Referenzimplementierung nutzt CDI (JEE-Standard für Dependency Injection) mit der Implementierung als Umsetzung von Dependency Injection. Sie ist grundsätzlich unter Java SE lauffähig, ihre Integration in Glassfish 4 zeigt aber ihre Kompatibilität zu einer JEE-Umgebung.
Mit Spring Batch existiert seit Jahren ein Projekt, welches sich mit Batchverarbeitung beschäftigt. Dieses Projekt wird mit der kommenden Version 3 die Spezifikation umsetzen.
Spring Batch bringt aufgrund seiner jahrelangen Historie eine Menge an Unterstützung mit. ItemReader und ItemWriterin Spring Batch stimmen zwar nicht in der Signatur der Interfaces mit JSR 352 überein, sind allerdings semantisch eng verwandt. Daher ist es möglich, Adapter für Spring Batch ItemReader/ItemWriters zu implementieren, falls diese in JSR 352 genutzt werden sollen (siehe https://glassfish.java.net/), um sich so aus dem großen Fundus von Spring Batchzu bedienen.
Der Standard macht keinerlei Aussagen über asynchrone Verarbeitung. Die Ablaufsteuerung ist synchron und gibt keinerlei Aussagen über die Kopplung von Steps.
Erst die Integration mit anderen Projekten wie Apache Camel oder Spring Integration erlauben die asynchrone Verarbeitung in Spring Batch.
Ausblicke
Bei der hier betrachteten Version handelt es sich um die Version 1.0 der Spezifikation, so dass auch nach eigenem Bekunden der Entwickler noch wichtige Aspekte unberücksichtigt sind.
So gibt es keinerlei Aussagen über die Verwaltung von Jobs. Es gibt weder normierte externe Schnittstellen wie JMXoder (restful) Webservices noch spezifizierte Konsolen/Webanwendungen zur Administration. Die Referenzimplementierung in Glassfish 4 bietet eine eigene, in Glassfish integrierte Konsole zur Administration von Jobs. Spring Batch bietet mit dem Projekt Spring Batch Admin eine webbasierte Lösung zur Verwaltung von Jobs an. In diesem Punkt scheint es bei anbieterspezifischen Lösungen zu bleiben.
Auch fehlen in JSR 352 jegliche Aussagen zur verteilten Ausführung von Steps, so dass in diesem wichtigen Punkt auf kommende Versionen der Spezifikation zu hoffen ist. Spring Batch adressiert diesen Aspekt durch die Zusammenarbeit von Spring Batch und Spring Integration und ist damit ein proprietärer Ansatz.
Fazit
Die Spezifikation JSR 352 ist möglichst nahe an den Konzepten von Spring Batch geblieben. Wo Spring Batch von JEEabweicht (z.B. Transaktionen, Nebenläufigkeit), sind die Anforderungen so formuliert, dass die Spezifikation nicht von anderen JEE-Spezifikationen abhängt und sowohl in Spring als auch in JEE umgesetzt werden kann.
Mit JBatch und auch mit Spring Batch 3 stehen stabile und bewährte Implementierungen bereit. Während Batchverarbeitung im Umfeld der JEE ein neues Mitglied ist, stellt der Umstieg auf JSR 352 für erfahrene Nutzer von Spring Batch kein großes Hindernis dar.
