La sortie de la plate-forme Java EE 7 ce mois-ci inclut la spécification pour un modèle de programmation de traitement en batch. Cette dernière est fortement inspirée de Spring Batch qui a également fait parler de lui ce mois-ci avec une remarquable version qui allège la configuration et simplifie l'accès aux données.
Application Batch pour la plate-forme Java, connue sous le nom de JSR-352, offre aux développeurs d'applications un modèle robuste pour le développement de systèmes de traitement en batch. Le coeur de ce modèle de programmation est emprunté à Spring Batch. Ce dernier a forgé le modèle Reader-Processor-Writer qui encourage les développeurs à adopter un mode de traitement orienté Fragment (Chunk).
Le modèle Reader-Processor-Writer se décompose en une chaîne de travail en trois étapes :
- La classe ItemReader est conçue pour consommer un fragment (chunk) des données de traitement (généralement un seul enregistrement) ;
- Un ItemProcessor, par lequel la logique business ou de domaine doit être imposée au fragment ;
- Et enfin, un ItemWriter, auquel les enregistrements seront délégués en post-traitement et regroupés par la suite.
Selon la spécification JSR, une Tâche (Job) est décrite par un document XML qui contient les étapes (Steps) du processus de traitement. Chaque Step décrit comment un bloc de données sera traité et l’intervalle de commit au sein duquel les données doivent être enregistrées. Des exigences plus complexes pour le traitement d'une étape donnée du workflow peuvent être traitées avec une batchlet. Définie dans le cadre de la JSR-352, une batchlet est équivalente à la tasklet de Spring Batch qui fournit une stratégie de traitement d'une Step.
La JSR-352 utilise également les mêmes modèles que Spring Batch pour l’accès et le contrôle des jobs. Les jobs sont invoqués par un JobOperator et les résultats d'un job sont accessibles via un JobRepository. Bien que le nom de JobRepository reste le même dans Spring Batch, JobOperator est connu sous le nom JobLauncher.
S'écartant un peu de la manière de définition des Jobs dans Spring Batch, les développeurs d'applications Java EE 7 doivent avoir les documents de Job XML dans le répertoire META-INF/batch-jobs de leurs projets. Avec Spring Batch, les développeurs peuvent placer leur configuration de Job dans un des fichiers de configuration du contexte d’application pour les rendre disponibles dans le conteneur Spring.
En plus de la taille du tampon, de l’intervalle de commits et de la politique de contrôle, les jobs XMLs de Java EE 7 définissent des implémentations concrètes de Reader, Processor et Writer. Une politique de contrôle indique la manière dont les commits seront traités, sa valeur par défaut est "item", mais on peut aussi choisir «time» comme stratégie. Dans le premier cas, l’intervalle de commit définit le nombre d’enregistrements traités, tandis que dans le second cas, il définit la durée en secondes.
<job id="myJob" xmlns="http://batch.jsr352/jsl">
<step id="myStep" >
<chunk
reader="MyItemReader"
writer="MyItemWriter"
processor="MyItemProcessor"
buffer-size="5"
checkpoint-policy="item"
commit-interval="10" />
</step>
</job>
La configuration des Jobs dans Spring Batch est presque identique à Java EE 7. La mise en garde était que Steps sont déclarés avec une directive tasklet. Les attributs reader, process et write de la configuration du fragment (chunk) font référence aux beans qui existent dans le contexte de l'application. Depuis la version 2.2.0, le commit-interval de la configuration du fragment indique le nombre d'éléments à traiter avant d'enregistrer le commit.
<job id="myJob">
<step name="myStep">
<tasklet>
<chunk
reader="myItemReader"
processor="myItemProcessor"
writer="myItemWriter"
commit-interval="2" />
</tasklet>
</step>
</job>
<bean id="myItemReader" class="...MyItemReader" />
<bean id="myItemProcessor" class="...MyItemProcessor" />
<bean id="myItemWriter" class="...MyItemWriter" />
Alors que la communauté Spring travaille actuellement vers la conformité JSR-352, Spring Batch va au-delà de la spécification afin d’offrir aux développeurs une intégration transparente avec les autres composantes de l'écosystème Spring. Dans le cas de traitements en batch, Spring Data peut être exploité directement comme une instance reader dans le modèle Reader-Processor-Writer, pour permettre aux développeurs de récupérer des fragments à partir d'un référentiel Spring Data. Client de Spring Data, la version 2.2.0 de Spring Batch réalisée ce mois-ci, offre un interfaçage simplifié avec les datastores MongoDB et Neo4j.
En plus de l’interfaçage simplifié du Reader, la dernière version de Spring Batch permet une extension de la configuration Java de Spring permettant de simplifier les fonctions de traitement batch. Pour permettre cette configuration simplifiée, les développeurs doivent seulement déclarer l'annotation @EnableBatchProcessing sur une classe annotée avec @Configuration. De là, les fonctions de traitement batch comme le JobRepository et JobLauncher peuvent être directement injectées (autowired) sans aucune configuration supplémentaire.
@Configuration
@EnableBatchProcessing
public class AppConfig {
@Autowired
private JobBuilderFactory jobs;
@Bean
public Job job() {
return jobs.get("myJob").start(step1()).next(step2()).build();
}
@Bean
protected Step step1() {
...
}
@Bean
protected Step step2() {
...
}
}
En plus des améliorations de la version 2.2.0 de Spring Batch concernant la récupération de données et la configuration, cette dernière version a mis à jour sa dépendance vers Spring avec la version 3.1.2 du framework comme version minimale. Les utilisateurs de Spring qui implémentent des applications batch devront se conformer à cette version minimale afin d’utiliser la dernière version de Spring Batch.