De retour du Mule Summit Paris 2010

Octo assistait le 6 octobre au Mule Summit Paris 2010. Pour l’évènement la direction technique polyglotte de l’éditeur est venue en force. Nous étions agréablement surpris par la richesse du contenu technique, en rupture par rapport aux conférences où se déplace toute l’équipe marketing, à grand coup de slideware. Difficile de rester insensible à l’esprit Open Source et communautaire derrière le modèle économique de MuleSoft.

Entre autres produits, tels que son middleware JMS et son serveur Tomcat enrichi, MuleSoft présentait les fonctionnalités de la v3 de son ESB sortie en septembre, et notamment la nouvelle architecture d’échange. C’est tout particulièrement sur ce point que nous nous étendrons ici, en passant en revue les trois modèles d’intégration disponibles. Pour rappel l’implémentation d’un flux dans Mule ESB se fait par configuration Xml ; comme c’est le cas avec les frameworks d’intégration Apache Camel et Spring-Integration.

Service-based configuration

Exemple de configuration Service-based

Ce cas typique de configuration service-based est caractéristique des ESB classiques. On résonne alors en demi-flux entrants et sortants, liés par un routeur.

Exemple de configuration Service-based

Cet autre cas typique de configuration service-based permet d’exposer sous forme de service un composant Java (POJO ou autre).

Tout service observe généralement cette configuration Xml :

<service>
 <inbound>
  <inbound-endpoint ... />
 </inbound>
 <component />
 <outbound>
  <outbound-router>
   <outbound-endpoint ... />
  </outbound-router>
 </outbound>
</service>

Dans le cas d’orchestrations complexes on atteint vite les limites de ce modèle d’intégration. On peut certes composer ces services à volonté, mais la configuration Xml devient alors trop verbeuse, au détriment de la maintenabilité. Bien que toujours supportée dans la nouvelle version, l’équipe technique annonce l’abandon progressif  de la configuration service-based. Configuration à laquelle il faut préférer les deux nouvelles approches que sont la configuration par pattern d’échange et la configuration par flux séquentiel.

Pattern-based configuration

La configuration pattern-based n’est pas fondamentalement différente de la configuration service-based, à ceci prêt qu’elle apporte énormément de concision dans le code Xml. Un pattern au sens Mule est un raccourci qui, en proposant un élément de configuration spécifique – une balise Xml - adresse une certaine problématique récurrente. Cette même problématique nécessitait auparavant un bloc entier de configuration Xml. Voici les quatre premiers patterns :

Le pattern <simple …>  permet l’exposition simple d’un composant sous forme de service.

Le pattern <proxy …> est un proxy web service.

Le pattern <bridge…> permet de définir rapidement un flux 1:1, quel que soit les transports utilisés.

Le pattern <validator…> permet de répondre de manière synchrone au client, tout en traitant le message en différé.

Au-delà de ces quatre éléments déjà disponibles, l’enjeu est de fournir une architecture ouverte, où éditeur et communauté peuvent enrichir l’ESB de nouveaux patterns.

Attention toutefois à l’évolutivité de vos flux. Ce qui correspond aujourd’hui à un certain pattern d’échange, pourrait ne plus y correspondre demain : contrainte de sécurité, service supplémentaire à appeler, etc. Je recommanderais simplement d’utiliser ces patterns avec prudence, et de privilégier la configuration flow-based au moindre doute.

Flow-based configuration

Toute opération dans Mule peut être désormais considérée comme une étape d’un flow, qu’il s’agisse d’une émission ou d’une réception de message, d’une transformation, d’un routage, etc. A partir d’un flow principal il est possible de déclencher d’autres flows, maximisant le reuse de flux :

Exemple de configuration Flow-based

Beaucoup plus légère, la configuration Xml – vulgarisée – d’un flow ressemble à ça :

<flow>
 <any-step ... />
 <any-step ... />
 <flow-invocation ... />
</flow>

On remarque que la configuration Xml suit strictement la logique séquentielle du flux. Le design d’une orchestration avancée est largement simplifié par rapport à la configuration service-based. Ce troisième modèle d’intégration offre le meilleur rapport entre productivité et maintenabilité.

Les limites connues

Mule ne propose pas de persistance des messages en transit. La première conséquence est qu’il n ‘existe pas de réel Publish-Subscribe. Le routage est déterministe et le couplage est fort entre demi-flux entrants et sortants. Pour un couplage complètement lâche, il faut nécessairement coupler l’ESB avec un middleware JMS. La seconde conséquence est qu’il n’y a pas de point de reprise dans l’ESB, à moins d’implémenter soit même le mécanisme avec des demi-flux et une persistance dédiés à la gestion des erreurs.

Ce qu’il faut en retenir

Concernant le déploiement, il était intéressant de voir que dans le groupe de participants, les deux principales options de déploiement était représentées ; à savoir standalone ou embarqué au sein d’une application. Mule ESB est utilisé en production sur des projets critiques, voire coeur de métier (plateforme collaborative complexe de dématérialisation de facture), en édition Community comme en édition Enterprise.

La conférence ayant eu lieu en petit comité – une cinquantaine de participants – les échanges avec l’équipe technique étaient d’autant plus enrichissants.  Mule ESB 3.0.0 marque un grand pas dans la simplicité et la productivité des développements d’intégration. Avec cette nouvelle mouture, l’ESB marque un rapprochement avec les Enterprise Integration Patterns (EIP), à l’image d’Apache Camel, et dans une moindre mesure de Spring-Integration. MuleSoft et la communauté sont particulièrement actifs, avec une roadmap très ambitieuse pour 2011. Si le sujet vous intéresse, je vous invite à suivre le blog officiel de Mule ESB.