JEE 7 Batch Processing - partie #1

Problématique

Les jobs ou batch sont une problématique récurrente dans les applications. Classiquement on a besoin de traitement batch pour injecter / extraire des données depuis un SGBDR, certains réseaux sociaux par exemple ont un gros besoin de batch. On peut imaginer qu’ils utilisent deux types de SGBD : un relationnel pour l’enregistrement et un no-sql pour l’affichage. Il est alors vital d’avoir une solution éprouvée pour copier les données saisies vers la base no-sql.

La problématique de traitement batch est très répandue et assez mal adressée dans le monde java. Il existe quelques solutions assez répandues, parmi lesquelles on peut citer :

  • quartz qui est framework pour planifier des taches / batch. Néanmoins cet outil ne propose rien concernant la constitution du traitement. Au final, tout le développement du batch (reprise sur erreur, checkpoints, partitionnement, traitement parallèle, enchaînement des étapes, workflow) reste à la charge du développeur,
  • les scripts shell : cette solution est éprouvée mais ne s’intègre pas au contexte d’un serveur d’application. Elle n’est pas liée à un serveur d’application lorsque la tache est planifiée avec une crontab. De plus dans cette solution le développeur doit gérer la création complète du batch : l’enchaînement des étapes, des checkpoints ou les traitements parallèle. On peut également s’aider d’un ordonnanceur tel AutoSys, qui reste à mon sens une solution plutôt orientée administrateur UNIX et non plus « javaiste »,
  • spring batch est un framwork très proche de JEE batch. Cette solution antérieure est efficace et mature mais ne s’intègre pas totalement au contexte d’un serveur d’application (quid de la gestion des threads dans les traitements parallèles). De plus il peut être gênant de devoir gérer un framework additionnel à JEE : compatibilité avec la version de JEE, montée de version, interaction lors de l’utilisation d’un socle de développement, intégration et utilisation sous WAS et ses différents classloaders.

C’est pour cela que l’API JEE batch se doit de répondre et de résoudre les diverses problématiques illustrées par les quelques exemples ci-dessus. De plus JEE doit suivre les changements et notamment pourvoir s’adapter à ce que propose le monde Spring pour ainsi rester une alternative fiable à Spring.

C’est pourquoi ce framework propose une API (dans le package javax.batch) qui s’intègre totalement à l’univers JEE 7. Elle propose une solution fiable et robuste pour la mise en place de traitements batch et pour la définition du comportement et du workflow de ces batch au sein d’un serveur d’application.

Présentation

La JSR 352 a pour vocation de permettre l’exécution de Jobs (ou traitements batch) dans le contexte d’une application JEE et donc d’un serveur d’application (Glassfish dans le cas présent).

Elle permet entre autre, de définir des checkpoints, de supporter les transactions, elle permet aussi morceler et paralléliser les traitements. Elle s’intègre à JEE et peut profiter, par exemple, des fonctionnalités des serveurs d’application : injection de dépendances (CDI), injection de contexte JNDI, gestion des transactions (JTA), etc.

Architecture générale

Architecture générale d’un batch

Concepts clé de l'architecture

Ci-dessus sont représentés les concepts clé de l’architecture. Un job définit des étapes (step), qui peuvent se suivre le modèle ItemReader / ItemProcessor / ItemWriter. L’instance de JobOperator propose une manière d’interagir avec un batch (il peut l’arrêter, le démarrer, le redémarrer, etc.) Chacun des éléments JobOperator, Job et Step sont associés à un unique JobRepository qui contient les métadonnées associées à l’exécution courante.

Eléments constitutifs d’un job

Eléments constitutifs d'un job

Le Job est l’élément qui encapsule l’ensemble des traitements d’un batch. Un Step est la définition d’une étape atomique. L’objet StepExecution correspond à une exécution particulière d’un Step. L’objet StepExecution pourra par exemple contenir des métadonnées décrivant l’exécution en cours. Un Job peut compter plusieurs Step enchaînés.

L’objet JobInstance correspond à l’exécution logique d’un Job. Un Job peut contenir plusieurs JobInstance car le Job peut être lancé par exemple une fois par jour. L’objet JobExecution pourra contenir les métadonnées décrivant l’exécution en cours.

L’objet JobExecution correspond à une exécution particulière d’un Job. A chaque fois qu’un Job est lancé une instance de JobExecution existe. Une instance de job peut être exécutée plusieurs fois : par exemple dans le cas d’un échec si l’on procède à un nouveau lancement.

Par ailleurs comme un Job correspond à plusieurs Step, une instance de JobExecution correspond également à plusieurs instances de StepExecution.

La configuration se fait de façon déclarative dans un fichier XML (couramment appelés  « Job XML »).

Exécution d’un job

Diagramme d'exécution d'un job

Dans le diagramme ci-dessus, pour chaque élément (item) de l’étape (des lignes d’un fichier par exemple), le Step invoque n fois le couple read() / process(). Une fois la liste d’éléments constituée, l’opération Write est appelée sur ces éléments pour, par exemple, les stocker en base, les enregistrer dans un fichier, les envoyer vers un flux de sortie, etc.


Nous verrons dans l’article suivant quel sont les éléments principaux constituant un job et comment les définir à l’aide de l’API de batch de jee7. Nous présenterons ainsi les éléments step (batchlet et chunck), nous présenterons également les points de sauvegarde (checkpoints), nous préciserons finalement comment l’api gère les erreurs lors de l’exécution des traitements.

Expert Technique Java / JEE

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !