Interview de Dave Syer, créateur de SpringBatch

Frédéric Tu et Moez Louati de SQLI Consulting ont eu l'occasion de croiser Dave Syer, créateur de SpringBatch lors de la conférence SpringOne à Anvers en mai dernier. Voici la retranscription de cette brève rencontre entre deux séminaires. J'en profite pour remercier Michael Isvy de l'avoir gentiment organisée.

Bonjour Dave, peut-on en savoir un peu plus sur toi et ton arrivée chez SpringSource ?
Depuis bientôt deux ans, je fais partie de l'équipe SpringSource. Depuis 2004 j'étais utilisateur du Spring Framework. J'ai tout de suite été charmé par ce produit. J'avais aussi l'avantage d'être en contact direct avec les équipes d'Interface 21. J'ai proposé en 2006 à SpringSource de prendre un congé sabbatiques afin de contribuer au framework sur mon temps personnel. Quand j'ai fait part à Rod Johnson de mon désir de le rejoindre pour quelques mois, il m'a fait une proposition d'embauche à la place ! Cela va faire bientot 2 ans que j'y suis et je ne le regrette aucunement.

Tu es le créateur de SpringBatch, peux-tu nous en dire un petit peu plus sur ce framework ?
Tout d'abord, ma philosophie est qu'une entreprise ne devrait jamais passer du temps à développer des composants qui ne sont pas liés à son coeur de métier ou qui ne contribuent pas à son chiffre d'affaire. Pour ce qui est de Spring Batch, ce framework répond à la problématique des batch de deux manières.

• La première, que j'appellerais "Infrastructure" est chargé de répondre à tous les besoins bas niveau et dont le code est assez récurrent et répétitif. Cette couche propose ainsi une boite à outils de composants génériques et prêts à l'emploi pour toutes les actions habituelles de manipulation de ressources (lecture de fichiers sous différents formats, gestion des connexions, ...).
• La deuxième partie concerne le modèle haut niveau, noyau même du framework appelé "Core Domain". Son objectif est de normaliser et gérer le cycle de vie du batch, "quelles sont les prérequis", "par quoi commencer" et "où finir". Elle offre une architecture haut niveau de composants modulables, qui doivent répondre à des besoins assez particuliers, avec une organisation des tâches assez précises. On parle de lancement de "jobs", composé de "steps" et chacune a une définition assez fine pour le suivi. Bien évidemment, la couche d'infrastructure s'intègre complètement dans ce modèle, avec la particularité d'être compatible avec tous les aspects de gestion des lots, sauvegarde d'état, reprise, ...

Quel est ton rôle dans Spring Batch et qui d'autre participe au framework ?
Je suis avant tout Consultant chez SpringSource et fondateur de Spring Batch. Je participe un peu à tous les niveaux, de la définition des objectifs, au développement tout en passant par la conception. J'y consacre environ un quart de mon temps, ce qui représente à peu près une semaine par mois. A part moi, un développeur SpringSource y travaille à plein temps. Spring Batch étant le fruit d'une collaboration avec Accenture, deux de leurs consultants consacrent une grande partie de leur temps à faire évoluer le projet, ce qui amène le noyau de l'équipe à 4 commiters. Spring Batch est déjà utilisé en production par au moins quarante à soixante projets répartis sur une quinzaine d'entreprises. Ces chiffres sont très approximatifs sachant qu'aujourd'hui (NdR 11 mai 2008), j'apprends à toute heure que de nouveaux développeurs utilisent ou évaluent mon projet.

Peux-tu nous dire quelles sont les prochaines étapes du développement de Spring Batch ?
Comme vous avez pu le voir, Spring Batch ne possède pas encore de console d'administration et de suivi. La version Spring Batch 2.0 devrait pouvoir proposer de déployer les batchs sur la plateforme S2AP. Le modèle de packaging S2AP a le mérite d'être assez claire et modulaire, permettant aux batches de s'inscrire dans ce modèle. Les batchs seront packagés en bundle, ce qui permet d'avoir un fichier facile à déployer sur la plateforme. Ensuite les lancements de batchs et le suivi pourra se faire à travers la plateforme applicative. De plus, les ressources pourront être configurées directement sur le serveur.

Est-ce que les batchs devront obligatoirement adopter le modèle de déploiement S2AP ?
La philosophie de Spring a toujours été de pouvoir s'adapter au besoin et de très peu imposer de conyraintes à ses utilisateurs. Les projets seront libres d'adopter la future forme de packaging ou de continuer à lancer les batchs par une simple fonction main().

Penses-tu que le grid computing sera implémenté un jour dans Spring Batch ?
Beaucoup de projets ont déjà eu ce genre de besoins et ont réalisés eux même les adaptations qui vont bien. En tout cas, Spring Batch proposera dans un future proche, un travail main dans la main avec Spring Integration. Les conférences vont bientôt reprendre, je vous invite à suivre ma présentation s'intitulant "Enterprise Integration with Spring Batch" ...