Mule 2 : présentation à JavaPolis 2007

Voici un compte-rendu en français de la présentation de Mule 2 de Ross Mason, le CTO et cofondateur de MuleSource Inc. Vous pouvez retrouver la vidéo en anglais à cette adresse. Bonne lecture.

Ross Mason a débuté le projet Mule en 2003. Avec un background en Finance et en Telco, Ross a débuté le projet Mule dans l’idée de créer un ESB open-source. Un ESB (Entreprise Service Bus) est un bus d’information, d’échange et de transformation de message. Mule remporte un succès car plus d’un million de téléchargement ont été effectués depuis la première version. 7 des 50 plus grosses entreprises dans le monde utilisent Mule. Il y a plus de 2500 développeurs sur les listes de diffusions, la communauté est donc active. 2000 applications sont en production avec Mule aujourd’hui.

La définition de Ross de Mule est « de permettre l’intégration de systèmes hétérogènes dans un même environnement ». Il s’agit de connecter différentes applications dont l’architecture est complétement différente. Un portail Web avec des sources de données. Des Services Adapters avec un bus de messagerie, etc.

Mule est composé d’un diffuseur de messages (Message Broker), d’un repository pour la configuration, d’un système de routage et de diffusions de messages, d’un moteur transactionnel, d’un moteur de transformation et enfin d’un moteur de gestion de workflow.

Mule peut donc recevoir un fichier, le transformer, diffuser via le routage des messages ou une partie de ce fichier à plusieurs applications, s’entourer d’une transaction pour réaliser le tout. La gestion de la sécurité est souple mais permet de gérer l’authentification et l’autorisation.

Pourquoi choisir Mule ?
Mule tout d’abord ne force pas un type de message. Que votre architecture se base sur l’échange de fichiers XML, CSV, d’objets sérialisés ou de flux binaires, le moteur de transformation de Mule permet d’ajouter ces différents formats.
Au niveau du code, Mule n’est pas intrusif et n’impose pas d’API externes. Les objets sont complètement portables, ce qui facilite les tests.
Le fait que Mule ne force pas le format des messages en fait un outil non compatible avec la spécification JBI de Java. Cependant je pense que c’est un avantage qui permet d’avoir un système plus ouvert. Renseignez-vous sur ce sujet, je n’ai pas plus creusé.

Mule a été comparé à un couteau suisse. Il offre un grand nombre d’architectures de services. ESB est l’une des topologies, mais Mule peut très bien faire du Client-Serveur par exemple, en se basant sur des échanges synchrones, asynchrones de type message ou de type commande (rpc). Pour cette raison c’est une solution souple.

Un service web de type requete-réponse synchrone peut ensuite faire suivre un message asynchrone à une Queue JMS par exemple. C’est le principe de Mule.

L’intégration avec l’architecture J2EE est optionnelle. Le support de JBI, JMS, EJB, des connecteurs JCA, de JTA et des Servlets permet à Mule de s’intégrer dans une architecture J2EE existante sans problèmes.

La partie routage des messages a été écrite en se basant sur le livre « Enterprise Integration Pattern » de Gregor Hohpe, , Bobby Woolf et Kyle Brown. C’est un livre de 2004 qui a encore beaucoup d’idées d’architecture simple.

La distribution transparente est une fonctionnalité de Mule qui permet de définir les règles d’échanges de messages dans la configuration. Ceci permet de faire des tests unitaires avec échanges de messages entre virtual machine, puis une fois en production d’utiliser un autre fichier de configuration avec des règles de distribution différentes. Très pratique dans le cadre des tests unitaires ou pour simuler (mock pattern) des interfaces clientes lorsque celles-ci ne sont pas disponibles. Pour la partie sécurité, Mule supporte JAAS ou Acegi pour l’authorisation.
Mule est capable de gérer des objets existants, des POJOs ou des EJBs. Enfin Mule est réputé pour faciliter les tests et un framework complémentaire à JUnit facilite l’écriture des tests.

L’architecture composant de Mule
Une instance de Mule est composée d’un Routeur entrant (Inbound Router), d’un composant unitaire (UMO Service Component) et enfin d’un Routeur sortant (Outbound Router).
Les routeurs sont connectés à différentes applications via des Channels. Un Channel peut être un client web service ou un fichier plat sur un répertoire par exemple.

Les nouveautés de Mule 2.0
La première nouveauté est un nouveau format de configuration XML basé sur des schémas, en lieu et place des anciennes DTD. Cela apporte pas mal de nouveautés pour la complétion de code dans IDEA IntelliJ par exemple. La configuration est plus simple et il n’est plus nécessaire de décrire toutes les classes. Un ensemble de XSD permet de simplifier la configuration des points d’entrées (endpoint).
Il est possible d’associer un Endpoint avec une méthode Java, via un Proxy Java. Il y a une Registry de configuration et donc il n’y a plus de Mule Manager. La gestion des messages a été améliorée. Un nouveau type de transformation peut être appliqué automatiquement lorsqu’un type de message est appelé. Mule peut prendre en charge certaines transformations simples.
Le Streaming est maintenant implicite pour les endpoints. Mule est gérable via JMX, ce qui facilite la gestion.

Mule est basé sur Spring pour sa partie configuration, cela se voit dès la lecture des fichiers de configuration. On retrouve l’idée de Spring 2.5. Son architecture est composée d’un Runtime Mule qui s’assure de la diffusion, de la gestion des Threads et des Transactions. La partie Transport supporte plus de 60 types différents. Cela inclus JMS, SOAP, Fichier plat, HTTP, FTP, SSH, JDBC, etc. La partie de routage permet l’échange de message. La partie transformation est capable d’effectuer un sacré nombre de tâches : XSLTC, CSV, Fix, ISO20022, Swift, objets Java… Il est possible d’appliquer un grand nombre de transformation.
Mule peut enfin démarrer un petit conteneur web pour simplifier la configuration.

Mule 2 configuration
Mule 2 se base sur le système de gestion d’espace de nomage de Spring 2. Chaque module a son propre espace de nom. Spring Bean peut être aussi ajouté dans la configuration de Mule 2. Le support de Seasar (sorte de Spring japonais) est aussi possible tout comme Hivemind ou Picocontainer.
La différence que j’ai vu entre Mule 1 et Mule 2 est que dans la première version de Mule, il fallait connaitre le nom des classes Mule pour déclarer les connecteurs. Mule 2 se basant sur des espaces de noms XML comme Spring, vous pouvez déclarer directement un attribut xml correspondant au connecteur qui vous intéresse. De plus les propriétés de chaque connecteur sont différentes selon le nom du module et la validation est possible dès l’écriture de votre configuration Mule.

Ensuite Ross présente un exemple simple de service Mule, qui permet de lire un message sur l’entrée standard pour créer un objet Order, puis ensuite d’appeler un service de gestion de la commande pour créer un objet ProcessedOrder.
Je retiens que Mule apporte toute la colle qui permet de créer le chemin suivant : lecture sur la console d’un message, transformation du message en objet Order, appel de la méthode process d’un service, récupération de l’objet ProcessedOrder et transformation de cette objet vers une String pour afficher un message de résultat. Le rôle de Mule via la configuration est donc de créer tous ces liens et d’orchestrer les appels des objets entre eux. Zéro ligne de code pour vous.

Ensuite un des intérêts ici est de montrer comment il est possible d’ajouter un nouveau point d’entrée sous la forme d’un service Web. Pour cela il déclare tout simplement une petite ligne dans le fichier de configuration, et via CXF un nouveau service web est automatiquement créé pour vous. Au lieu d’utiliser la console et l’entrée standard, vous pouvez maintenant appeler une méthode d’un service web pour refaire le même parcours.
Si je résume : Mule permet d’ajouter via une ligne de configuration un nouveau point d’entrée à votre application.

Il montre ensuite comment appeler un service de vérification de crédit durant la transaction. Lorsque la commande est créé, on souhaite effectuer un appel à un service HTTP distant capable de nous dire si la carte de crédit est créditrice ou non pour valider le paiement. Le service est modifié pour recevoir par injection un objet CreditChecker. Le code est vraiment simple et on ne voit aucunes informations de transport, il est impossible de voir qu’il s’agira d’un appel HTTP ou via un Web Service. Mule crée du code agnostique et la partie transport/communication est masquée de son côté. Cela facilite en effet les tests unitaires.

Il montre ensuite un nouveau système d’extraction et de création des propriétés à l’execution. L’exemple qu’il montre est l’envoi d’un email à un destinataire, l’email est extrait avec une expression XPath à l’exécution.

Autres nouveautés
Mule 2 a été réécrit pour faciliter la gestion des clusters. Mule 2 est prêt aussi à fonctionner avec OSGi car cela permettra d’apporter la gestion de version d’OSGi à Mule, ainsi que le déploiement à chaud. La gestion de version permettrait de ne redéployer qu’une partie de votre application et de ne mettre à jour que ce qui est nécessaire.

La gestion du Streaming
Mule 2 est capable de gérer de gros volumes de données sans essayer de tout charger en mémoire. C’est indispensable par exemple lors de la génération de rapports financiers. Les données étant énormes, lorsque nous avons travaillé avec Kocktail chez Reuters je me souviens que cette partie était délicate. Si c’était à refaire aujourd’hui, je serai tenté de regarder si Mule ne peut pas aider et faciliter l’architecture de ce composant. Hasan si tu me lis… tu sais quoi faire.

La gestion des erreurs
La gestion des exceptions est importante car pour la gestion des connecteurs c’est ce qui apporte des règles de tolérance de pannes. Pour les exceptions des connecteurs (un service web distant est tombé…) il est possible de configurer dans Mule des règles de routage différente pour gérer les problèmes réseaux par exemple. JMX permet de surveiller un composant Mule afin de détecter des pannes, chose importante pour l’exploitation et les équipes de production (spéciale dédicace à Gik de l’INA).

Les transactions
A mon avis c’est la partie la plus délicate de Mule. Tout se configure via les fichiers de configuration. Mule supporte les transactions de type Local ou XA. Plusieurs serveurs d’applications sont supportés comme Weblogic ou JBoss. Le support d’Arjuna ou Atomika est aussi possible. Mule peut utiliser les gestionnaires de transaction des serveurs d’application comme Weblogic par exemple, en passant via JNDI pour retrouver le gestionnaire de transaction.

La montée en charge
Dans ce slide, Ross explique pourquoi Mule est scalable. Mule est basé sur le modèle SEDA (Straged Event Driven Architecture).
Je fais une aparté pour parler de SEDA, ou de ce que j’en ai retenu en lisant le PDF.
Le problème : comment gérer un grand nombre de requêtes dans un serveur ? Quelle est la meilleur architecture pour traiter 1000 requêtes à la fois ?

Tout d’abord voyons l’architecture multi-threadée classique :
Un serveur Web classique peut par exemple démarrer une thread par requête. Si cela semble une bonne idée au premier abord, charger une image du disque ou faire un appel dynamique à un EJB ne coûte pas la même énergie. Et ce modèle threadé est donc « bête » car il consomme des Threads pour des choses simples. Pour répondre à cela, est apparu les modèles orientés événement comme celui au coeur de Flash. A chaque événement système un ordonnanceur envoie des événements à un nombre limité de threads qui gérent une machine à état. Imaginez la distribution de cartes dans une partie de Poket. Il y a 5 joueurs et le donneur donne des cartes. Certains joueurs vont terminer le boulot avant les autres (se coucher…) et d’autres vont travailler plus longtemps. Le souci de cette 2ème architecture de distribution est que l’on assume que la lecture des événements n’est pas bloquant. En clair, cela veut dire que lorsque je distribue les cartes, mes joueurs ne me bloquent pas et je passe au joueur suivant. Or c’est parfois difficile en vrai. De plus, si l’une de mes Threads prend 90% du CPU pendant que je distribue mes tâches, je suis impacté et toute l’application se met à ramer.
Pour revenir à mon exemple avec le poker, la limitation de l’architecture orienté message est que lorsque l’ordonnanceur (le donneur) distribue les cartes il n’attend pas la réponse de chaque joueur et donc il va très vite, sans s’arrêter. Si ensuite il doit être bloqué par un joueur, comme lorsqu’il demande ce que veut faire le joueur, alors le modèle est bloqué. Donc ce type de distribution des tâches fonctionne tant que les machines à état ne bloquent pas le scheduler.
Pour cette raison, SEDA propose une 3ème architecture. Tout d’abord on ajoute la notion d’étape, pour que la gestion d’un événement soit effectué par petite étape très rapide. Ensuite on ajoute des queues pour effectuer la gestion des événements. Enfin SEDA fonctionne avec un système d’allocation dynamique des ressources afin d’ajuster à la charge le nombre de Threads. Tout ceci mis en place dans Mule promet donc une architecture mature et capable de monter en charge. La gestion des Threads est un cauchemar, je n’ai jamais vu une application parfaite en Java 1.4.
Je me souviens d’une discussion avec un ami, Flavien, qui m’expliquait que son équipe avait écrit un moteur d’envoi de MMS massivement parrallèle. L’implémentation initiale en Java se trainait à 100 MMS par seconde. Une nouvelle implémentation en C avec une architecture différente permet maintenant d’envoyer entre 2000 et 3000 MMS à la seconde…

Pour Mule, le modèle SEDA est appliqué à JMS dans Mule ainsi que la notion de Spaces emprunté à Java Spaces.

Load balancing et Failover
Ross présente dans ce slide les capacités de répartition de charge et de gestion des pannes de Mule 1 et Mule 2. Mule 2.1 aura un support natif du clustering.

MuleForge
MuleForge est une communauté destinée aux utilisateurs de Mule pour partager des projets basés sur Mule. Par exemple des Transformers spéciaux, des connecteurs pour SAP, Salesforces.com, SIP ou SMS par exemple. Il y a déjà 80 projets hébergés sur ce site.
Allez voir la page http://www.muleforge.org/activeprojects.php qui contient des connecteurs pour du Single Sign On, du LDAP, du SFTP, etc.

Mule HQ
Il s’agit d’une console de surveillance et d’administration qui permet via JMX de surveiller des instances Mule. C’est un peu le domaine sur lequel j’ai travaillé pour l’INA afin de surveiller et d’administrer des serveurs avec une application en Flex. Intéressant de voir ce que Mule propose, c’est une réelle demande des équipes d’exploitation et de production.

Ensuite Ross présentera MuleIDE, un plugin pour Eclipse qui facilite l’écriture de modules Mule.

Conclusion
Voilà c’est tout pour cette transcription, j’espère que cela vous aura donné envie de tester Mule et d’y penser pour vos prochaines architectures.
A bientôt.

Annexes

• Le site de Mule : http://www.mulesource.com/
• Blog Octo : http://blog.ippon.fr/tag/ross-mason
• Livre Enterprise Integration Pattern sur Amazon.fr

Articles similaires:

Exemple Mule : lire un fichier CSV et écrire vers une base de données Introduction à Spring Integration Présentation de GateIn beta 2 et eXo Portal mardi 27 octobre Présentation de la JSR-296, Swing Application Framework