Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

Spring 2.5 : une histoire

    Home Java Spring 2.5 : une histoire

    Spring 2.5 : une histoire

    Par Nicolas Martignole | Java | 2 commentaires | 17 avril, 2008 | 0 | 920 affichages
         

    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.

    Articles similaires:

    Default ThumbnailSpring : keep-it under control Default ThumbnailIntroduction à Spring Integration Default ThumbnailEvénement Spring à Paris le mercredi 4 novembre 2009 Default ThumbnailEvénement Spring le 13 novembre 2008
    spring
    • Avatar
      ohnerom 18 avril 2008 at 8 h 59 min

      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 ….

    Recent Posts

    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021
    • FizzBuzz en Java et Scala (surtout Scala)

      L’exercice FizzBuzz est un petit exercice très simple, à tester par exemple

      9 février, 2021

    Recent Tweets

    • RT  @JosePaumard : Il y a tout juste un an j'ouvrais ma chaîne de cours Java en ligne (près de 80h de cours), c'était la fermeture des univer…

      2 hours ago
    •  @ShirleyAlmCh  Ça fait du bien de te lire

      3 hours ago
    • RT  @kimchy : great read from  @ldoguin  on putting customers first to the benefit of all by cloud vendors, wonderful to see it embraced by  @cl …

      13 hours ago
    •  @juliendubois   @alexismp  Interesting. However I tweet mostly in French so how accurate is this graph ?

      1 day ago
    • Et hop, voici la future liste des talks 2021 https://t.co/kQPehA8uzx avec encore quelques ajustements à faire (masq… https://t.co/mIDLEw0sML

      1 day ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express