Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Sessions intra-entreprises sur demande : contact[at]mokatech.net.
Inscrivez-vous vite !

Java BarCamp #2 : compte-rendu (2/2)

Ce billet fait suite à la première partie du compte-rendu du Barcamp de décembre, décrivant la table-ronde portant sur la génération de code.

Pour la deuxième séance, j'ai sélectionné le thème "ESB : Mule et Spring Intégration", car c'est un domaine que je ne connaissais pas. Je n'étais apparemment pas le seul, puisque plus de 15 personnes se sont pressées dans la salle pour profiter des retours d'expérience de Julien Dubois (SpringSource), Nicolas Martignole (le Touilleur-Express) et Florent Ramière (Jaxio) sur ces technologies.

ESB : Spring Intégration et Mule

Spring Intégration

Sous la pression populaire (il croyait venir en touriste, c'est raté), Julien a tout d'abord présenté Spring Intégration.
Disponible en version 1.0 depuis début décembre, Spring Intégration n'est pas officiellement appelé ESB à cause de la connotation de lourdeur que ce sigle véhicule. Revendiquant au contraire une grande légèreté, il est prévu pour fonctionner sur de petits serveurs, et même être lancé au sein de tests unitaires.

Comme tout ESB, Spring Intégration est un peu l'équivalement moderne de l'opératrice téléphonique : il permet de mettre en relation des ressources d'entreprise. Par exemple, il est facile de scruter un répertoire de fichiers de log au format CSV, d'extraire les dix premières lignes de chaque fichier, de les transformer en HTML et de les envoyer par mail à un administrateur si elles contiennent une trace de niveau "erreur".

Cet exemple nous permet de reconnaître les principales briques constitutives des ESB :

  • Les adapteurs de protocoles : ici, lecture du système de fichiers, et protocole SMTP pour l'envoi du mail
  • Les transformateurs : lecteur de CSV et générateur de HTML
  • Les routeurs : sélection du bon destinataire (ici, l'administrateur) en fonction de propriétés du message)

Spring dispose déjà de tous les connecteurs principaux, et pourra, à terme, utiliser également ceux du projet Apache Camel. Les messages échangés entre les connecteurs sont en pur Java (Message<T>), ce qui permet d'éviter les conversions vers/depuis un format pivot XMl, comme le fait OpenESB.

Spring oblige, la configuration est principalement réalisée en XML. Florent, s'inquiétant de la verbosité de cette solution, demande s'il est possible d'utiliser des annotations. C'est effectivement possible, et tous s'accordent rapidement sur l'idée que les annotations sont effectivement préférables pour définir la configuration interne au système, plutôt figée, tandis que le XML reste indispensable pour la définition des interactions externes.

Quelques success stories sont déjà au crédit de Spring Intégration, principalement à l'étranger, même si une banque et un opérateur télécom nationaux sont en train de le tester.

Mule

Nicolas a ensuite présenté Mule, qu'il a mis en place chez plusieurs clients.

Mule est un ESB léger, qui tourne également le dos à la norme EBI pour gagner en souplesse et en performance. Pour cela, il a adopté l'architecture SEDA (Staged Event-Driven Architecture), dont le principe est de disposer d'unités de traitement autonomes reliées par des queues de messages (Mule utilise des queues virtuelles in-memory pour des raisons de performance). Il permet en outre de définir quelles opérations sont synchrones ou non, et gère les transactions distribuées entre plusieurs types de connecteurs.

Nicolas définit Mule comme une "multiprise inter-applicative", permettant d'ajouter à peu de frais des connecteurs FTP, JMS, mail, HTTP... à des applications legacy, plutôt que de réinventer une roue carrée. Il le trouve techniquement très simple à mettre en place, mais avertit que les bons patterns d'intégration sont généralement délicats à trouver. Par exemple, à qui revient la gestion des exceptions métier ?

Quelques digressions autour du portfolio SpringSource

Suite à une question de Nicolas, Julien nous a brièvement parlé de Spring Batch.

En version 1.1 depuis juillet 2008, ce projet s'inspire largement des batches Cobol, dont il reprend la sémantique : jobs, steps...
Il s'appuie sur une base de données pour persister son état, afin de garantir une bonne reprise sur incident, et, accessoirement, éviter de traiter plusieurs fois une même tâche. Particularité intéressante, cela lui permet également de rendre transactionnel le traitement de certaines ressources qui ne l'autorisent habituellement pas, comme par exemple les fichiers textuels : il est ainsi possible de traiter atomiquement des blocs de 100 lignes, de reprendre le traitement à un certain point au lieu de recommencer au début, etc.
Selon Julien, un soin particulier a été apporté à l'optimisation des performances à tous les niveaux.

La future version 2.0 apportera son lot de nouveautés intéressantes : uen console d'administration (même si Spring Batch 1.1 peut être monitoré par l'Application Management Suite), la parallélisation des traitements, la distribution sur plusieurs serveurs, des traitements conditionnels, et le support d'unités de transformation des données.

La conversation a ensuite dérivé sur Spring DM.
Nicolas trouvait la technologie intéressante mais s'inquiétait de la facilité de déploiement des modules OSGi et de la gestion des dépendances, notamment face aux EJB 3. La réponse est simple : les différents modules d'un projet peuvent être assemblés au sein d'un ".par" (Platform ARchive), qui peut être auto-déployé par le serveur et calcule automatiquement l'ordre de déploiement optimal.
Julien nous a rapporté l'anecdote d'un client qui avait même utilisé un EAR sur Spring DM : celui-ci a simplement détecté le projet web qu'il contenait,et l'a déployé sans problème !

Conclusion

La seconde séance du Barcamp fut très intéressante, en particulier grâce à la qualité des intervenants. J'ai pu avoir un bon aperçu des cas d'utilisation et de l'architecture de deux des principaux ESB, domaine que je n'avais pas encore eu l'occasion d'aborder.

J'attends donc avec impatience le prochain Barcamp. Soyez sûrs que je vous tiendrai au courant dès que sa date sera fixée !


Commentaires

1. Le dimanche 21 décembre 2008, 09:53 par Nicolas Martignole

Merci olivier pour ton compte-rendu.
Juste un point à préciser lorsque tu dis "..et utilise principalement des queues JMS pour transférer les messages entre les unités de traitement..."
Mule est un assembleur léger qui met en relation différents types de protocoles (dont JMS). En interne, il propose et utilise des queues virtuelles de mémoire partagées (le vm://) mais pas de JMS.
Cordialement, Nicolas.

2. Le lundi 22 décembre 2008, 03:01 par Olivier Croisier

Merci pour cette rectification, j'ai modifié le paragraphe !

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.