Il est temps de réparer un oubli : je n’ai presque jamais parlé de Spring ici. Depuis février nous avons mis en production un projet basé sur Spring 2.5. La mise en production s’est effectuée cette semaine à New-York, chez un gros hébergeur financier, client de nos produits. Un de nos développeurs est là-bas et termine les tests.
Tout a commencé en décembre. Notre framework web génère des fichiers Excel et PDF à partir de rapports financiers qui sont dans un format propriétaire. Cela fonctionne sans soucis pour des petits rapports. L’utilisateur navigue dans l’interface web, sélectionne un rapport puis lance une action « Export to Excel ». Une servlet effectue alors le traitement. Classique, pas de quoi se relever la nuit.
Cependant lorsque le volume de données est trop important, tout un ensemble de soucis apparaissent : l’utilisateur est bloqué pendant le traitement de l’export. La mémoire et le CPU du serveur d’application est fortement sollicité. Ce qui conduit même à ralentir les autres utilisateurs connectés au client léger web…
Nous avons tout d’abord désynchronisé cette partie. Via un MDB, le code de l’export est exécuté de manière asynchrone. L’utilisateur est notifié dans son navigateur par un icône lorsque le traitement est terminé. Cette piste n’est pas la bonne : vous ne retirez pas la charge et le besoin en puissance pour créer l’export. Bref retour à la case départ.
Je cherche une solution facile à mettre en place par l’équipe en 4 semaines. Le client attend une solution qui tienne la route pour passer en production, donc pas le temps de tergiverser. Et là, la solution la plus simple et la plus rapide : Spring 2.5 !
Dans la même semaine je croise Julien Dubois qui est l’auteur du très bon livre Spring par la Pratique aux éditions Eyrolles. En effet toute la partie JMS de Spring nous servira ensuite à implémenter une solution propre.
En 7 jours, nous écrivons une application Spring simple, qui utilise Spring-JMS. Cette application que j’ai baptisé « Kocktail » se connecte au serveur JMS du serveur d’application, dépile d’une Queue un message, génère le fichier Excel ou PDF puis reposte sur une Topic un message de résultat, indiquant que le rapport est prêt.
Kocktail car l’application charge un rapport financier, un template de rendu et génère un fichier Excel ou PDF assez complexe.
Les fichiers générés sont assez volumineux. Nous avons donc décidé de partager un répertoire entre le serveur d’application et la partie Kocktail. Il était or de question d’envoyer via JMS des fichiers Excel de 3 à 30 Mo.
Au final nous avons fait un passage en production au début de cette semaine. Avec quelques petits ajustements mais on est resté sur notre solution Spring. La solution peut monter en charge car il est possible de lancer plusieurs processus Java « Kocktail ». Sur un serveur multi-core cela donne de biens meilleurs résultats. Et surtout, du côté de l’interface utilisateur, nous n’avons plus de ralentissement. Je sais que c’est la base d’un ESB. Mais allez tout changer en un mois… impossible pour moi. J’ai fait au plus simple.
Mes impressions sur Spring : facile à mettre en œuvre, souple et pratique. La première piste avec les MDB a mis en lumière les soucis de la plateforme J2EE : obligé de déclarer tout un ensemble de XML, de s’assurer que cela fonctionne ensuite avec JBoss, Weblogic et Websphere… Et le nom des Queues/Topics fixés en dur dans l’EAR… non merci.
Avec Spring, nous avons ajouté une partie Spring client JMS dans notre framework afin que lors de l’export, un message soit posté sur une Queue configuré dans Weblogic ou JBoss. Facile, simple et pratique. Nous n’avons pas eu besoin de sortir une solution plus puissante basée sur Jencks par exemple. Notre besoin est assez simple.
En résumé, je pense qu’il est important d’apprendre Spring, qui permet d’attaquer des problèmes J2EE en partie causés par la lourdeur de cette architecture.
C’est tout sur spring ? pour ma part, il y a plus un seul projet ou j’utilise pas spring 🙂 Je trouve qu’il y a 3 axes d’améliorations , pas forcement venant de spring directement :
IOC ou DI : code mieux cloisonné, simplifié et testable unitaire.
spring : brique logiciel tecnhique ou fonctionnnel réutilisable induite.
spring : ‘couche ou abstraction’ technique fournie par défaut par des implémentations du framework. ( injection des properties, publication via RMI d’un service metier, connecteur EJB, gestion des transaction, etc …le tout sans intrusion 🙂 )
et il y a encore beaucoup à dire ….