Beliebte Suchanfragen
|
//

10 Kriterien für die Wahl der richtigen JSR-352 – Implementierung (Java Batch)

5.12.2013 | 4 Minuten Lesezeit

Der Java Specification Request 352 (JSR-352) ist die Standardisierung der Batch-Verarbeitung in Java und zielt dabei sowohl auf die Java Enterprise Edition (JEE) als auch auf die Java Standard Edition (JSE). Er wurde dieses Jahr freigegeben und ist Teil von JEE7, und das bedeutet wiederum, dass in Zukunft jeder JEE7 Application Server die Fähigkeit haben wird, Batch-Jobs durchzuführen. Aber auch wenn der Application Server gesetzt ist, hat man immer noch eine Wahl bei der Implementierung des JSR-352 . Wenn der Application Server nicht gesetzt, hat man natürlich noch mehr Wahlmöglichkeiten.
Okay, man hat also die Wahl, aber wie wählt man nun aus? Natürlich geht es hier nicht um die Features, die der JSR-352 bietet, denn die bietet schließlich jede Implementierung. Es geht um das, was darüber hinaus geboten wird. In diesem Artikel habe ich zehn Kriterien zusammengestellt, die auf Erfahrungen bei der Einführung von Spring Batch in typischen Enterprise Firmen wie Versicherungen und Banken basieren. Bisher gibt es keine ernstzunehmende Implementierung des JSR-352, auch Spring Batch ist noch nicht so weit, also kann man bisher auch keine Vergleiche durchführen. Aber sobald es Implementierungen gibt, können die folgenden zehn Kriterien als Basis für den Vergleich dienen. Sie sind nach Wichtigkeit geordnet.

  1. Testbarkeit
    Es sollte möglich sein, Batch-Jobs als JUnit-Integrationstest laufen zu lassen, ohne dass man den Job auf dem Application Server deployen muss. Entwicklerproduktivität und die mögliche Testabdeckung sind so sehr viel höher.
  2. Komponenten
    Ein sauberes Programmiermodell für Batch-Jobs ist schön und gut, aber richtig schnell wird man in der Entwicklung erst, wenn einem vor-definierte, gut getestete Komponenten zur Verfügung stehen. Spring Batch hat jede Menge ItemReader, ItemWriter, PartitionHandler usw. für alle möglichen Arten von Daten und Infrastrukturen.
  3. Monitoring
    Der JSR-352 definiert Batch-Job – Metadaten wie JobExecutions, JobInstances, StepExecutions und so weiter. Es sollte einen guten Weg geben, auf diese Daten über eine GUI zuzugreifen, auf der man Jobs auch starten, stoppen und überwachen kann. Spring Batch hat dafür die Spring Batch Admin – Webanwendung. Zusätzlich sollte es Endpunkte für die automatische Überwachung geben wie beispielsweise JMX.
  4. Community
    Eine Entwickler-freundliche Community bringt viel Produktivität. Hier sollten Google-Resultate, ein aktives Forum, Aktivitäten auf Stackoverflow geprüft werden, um zu sehen wie sich das jeweilige Produkt in dieser Kategorie schlägt.
  5. Vererbung bei Jobs
    Dieses Feature mag sich nicht so wichtig anhören, tatsächlich wird es aber in fast jedem Spring Batch Projekt, das ich kenne, genutzt. Größere Firmen haben normalerweise Anforderungen, die jeder Job erfüllen muss, beispielsweise bei der Protokollierung, beim Logging, bei der Exit-Code-Konvertierung. Entwickler sollten die dazu benötigten Konfigurationen nicht für jeden Job neu definieren, sondern von einem abstrakten Job erben, der diese mitbringt. Auch in Projekten mit vielen sehr ähnlichen Jobs wird so eine Vererbung immer wieder genutzt. Der JSR-352 definiert diese aber nicht.
  6. Open Source
    Die Diskussion, ob Open Source nun gut oder schlecht ist, werde ich hier nicht noch einmal führen, aber habe doch eine klare Meinung. Als Entwickler möchte ich einfach nicht vor die Closed-Source-Wand laufen, wenn ich debugge, und eine nachvollziehbare Code-Qualität ist unheimlich viel wert. Als Entscheider würde ich das Open Source Projekt natürlich kritisch prüfen, aber immerhin kann man das auch ohne Probleme.
  7. Security
    Security ist immer wichtig, nicht jeder sollte Jobs starten und stoppen dürfen, und nicht jeder sollte die Batch-Metadaten einsehen dürfen.
  8. Skalierungsoptionen
    Skalierung ist wichtig, und ich habe es nur deshalb als Punkt acht einsortiert, weil die wichtigste Skalierungsoption – Lokale Partitionierung – im JSR-352 definiert wird. Aber es gibt noch mehr (in Spring Batch: Multi-threaded Step, Remote Partitioning, Parallel Step, Remote Chunking), also sollte geprüft werden, welche weiteren Skalierungsoptionen angeboten werden.
  9. Konfigurationsoptionen
    Der JSR-352 definiert ein XML-basiertes Konfigurationsmodell für Jobs. Spring Batch bietet darüberhinaus Konfiguration in Java, die type-safe ist, viele Dinge schon zur Compile-Zeit sicherstellt (nicht bei der Ausführung) und Refactoring in jeder IDE unterstützt. Das ist nicht kritisch bei der Einführung eines Batch-Frameworks, deshalb ist es an Platz neun, aber dennoch kann es einen Produktivitätsunterschied machen, und es ist gut, die Wahl zu haben.
  10. Erweiterbarkeit
    Erweiterbarkeit ist ebenfalls sehr wichtig, und es ist hier nur an Stelle zehn, weil die API des JSR-352 das allermeiste von dem, was man für Erweiterungen benötigt, bietet, wie das Starten und Stoppen von Jobs, der Zugriff auf Batch-Metadaten und das Schreiben eigener Komponenten. Trotzdem kann es Erweiterungsbedarf geben, der nicht vom JSR-352 abgedeckt wird.

10 Kriterien, manche relativ umfassend, manche ein konkretes Feature. Die Reihenfolge habe ich mit der Erfahrung der Einführung von Spring Batch in größeren Firmen aufgestellt. Man mag die Reihenfolge vielleicht etwas anders sehen, man mag einen Punkt entfernen und vielleicht einen hinzufügen, aber im Endeffekt sind es wichtige Punkte. Eine Implementierung des JSR-352 sollte mit Bedacht ausgewählt werden, denn sehr wahrscheinlich bleibt sie einem für längere Zeit erhalten. Diese Kriterien werden Ihnen helfen, eine Implementierung zu wählen.

|

Beitrag teilen

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.