Les ESB, exemple particulier de Mule ESB

A la fin de l'article qui va suivre, vous aurez joué avec la sympathique api spellcheck de google sans avoir écrit la moindre ligne de code  (savoir dézipper des archives et créer des dossiers dans l'explorateur de votre OS restent cependant indispensables). Mais avant d'en arriver là, je vous parlerai un peu des fondamentaux de la SOA et de l'utilisation des bus d'entreprise dans ce contexte.

Rappels sur la SOA

Un besoin récurrent des DSI est de parvenir à faire communiquer entre elles des applications qui au départ n'avaient pas vocation à le faire, de pouvoir réutiliser des composants déjà développés ou encore de réduire les couplages pouvant exister entre différents modules du système d'information. La SOA ( Architecture Orientée Services ) est un ensemble de principes et de méthodologies pour la conception, le développement et l'intégration de solutions logicielles qui tente de répondre à ces attentes. Ce point est important ! La SOA n'est pas une technologie, c'est une façon de penser son SI !

La notion de Service est centrale en SOA. Dans ce contexte, un service est un composant à forte valeur ajoutée métier et il remplit les conditions suivantes :

  • Il définit un contrat connu des autres systèmes;
  • Il est unique;
  • Il est invocable à distance par n'importe quel programme;
  • Il est possible de le localiser (à terme via un annuaire).

Chaque service doit se conformer au contrat qu'il a publié et le reste du système n'est pas tenu de connaître son implémentation ou ses évolutions.

Enterprise Service BUS (ESB)

Un Enterprise Service Bus (au sens architecture du terme) est devenue l'implémentation commune de la SOA. Il s'agit d'un ensemble de règles et de principes qui vont permettre d'intégrer plusieurs applications du SI qui pourront communiquer entre elles en s'adressant uniquement à un bus. Les ESB (au sens outils middleware disponibles sur le marché tels que Mule ESB, Apache ESB, Sonic ESB) vont donc nous permettre d'implémenter une telle architecture.

Schéma de fonctionnement d'un ESB

De fait, les principales promesses d'un ESB sont les suivantes :

  • Connectivité vers des technologies diverses (doit s'adapter à tous les protocoles et formats de données présents dans le SI et doit donc supporter le plus de standards de l'interopérabilité possible (web services, xml, jms, fichiers plats, etc.) mais aussi le cas échéant proposer des connecteurs spécifiques en cas de formats propriétaires dans le SI;
  • Routage (c'est l'ESB qui déduit le destinataire d'un message à partir du contenu de celui-ci car on souhaite découpler l'ensemble consommateur/producteur);
  • Transformation (capacité de l'ESB de transformer les messages circulant sur le bus par exemple d'un format vers un autre avant envoi vers un service cible);
  • Monitoring (garantie que les messages seront lus et livrés; sécurisation des services, garder traces des échanges...);

A ces promesses essentiellement techniques, peuvent venir s'ajouter :

  • le Business Activity Monitoring (BAM) qui permet de suivre l'activité d'un processus métier.
  • le Business Process Management (BPM) qui va gérer l'orchestration des processus métier.

Dans la suite de cet article, nous allons nous atteler à exposer plus en détails les capacités des ESB au travers de quelques d'utilisations concrets basés sur Mule ESB.

MULE ESB

Installation

Il s'agit d'un ESB développé par Mulesoft et dont la version communautaire est téléchargeable sur http://www.mulesoft.org/download-mule-esb-community-edition.
Il existe également une version entreprise payante (après essai de 30 jours).
Mule ESB est actuellement disponible en 2 versions; une embarquant un éditeur reposant sur eclipse et permettant de créer ses projets à travers une interface graphique
plutôt sympathique d'ailleurs et une autre en standalone. Dans cette version, il faudra prévoir plus de configuration xml pour modéliser le processus.

Ici pour déployer Mule, nous avons utilisé la version mule-standalone-3.3.0 pour permettre de mieux comprendre le fonctionnement de l'application.

Configuration

Après avoir téléchargé et dézippé dans un répertoire donné la distribution, il faut créer une variable d'environnement MULE_HOME pointant vers le répertoire d'installation de Mule. Rajouter ensuite au PATH le chemin MULE_HOMEbin est également souhaitable. Il suffit alors de lancer "mule" en ligne de commande et ça y est, ça fonctionne !

Architecture de Mule ESB

Comme dit précédemment, le travail premier de Mule est de connecter des applications, donc de recevoir des messages et d'en envoyer. Un traitement qu'effectue Mule sur un message est modélisé dans l'application par un FLOW. Techniquement, ce FLOW est représenté au sein de notre application par un fichier xml.

Dans un flow, nous allons définir en ensemble de ENDPOINTS, dans un ordre déterminé qui peuvent représenter chacune des étapes de notre traitement.  Un ENDPOINT représente le moyen par lequel Mule va communiquer avec un système extérieur. Ils sont divisés en 2 types : les inbounds et les outbounds. Dans un flow, le point d'entrée du processus sera un inbound, tous les autres seront des outbounds. Pour chaque endpoint, en fonction de son type (JMS, file, web services, ...), il existe un certain nombre de paramètres (obligatoires ou non) qui vont nous permettre de préciser le mode de connexion et certains comportements supplémentaires que nous souhaitons pour notre endpoint.

Dans un flow, nous pouvons également définir des transformers, traitements qui, comme leur nom l'indique, vont permettre à Mule de passer d'un type de données à un autre. Mule par défaut supporte déjà un grand nombre de transformation (File to String, JMSMessage to Object, Object to byte array, ...). Bien sûr, il est possible de créer ses propres transformers.

Il est également possible d'enrichir son flow, d'expressions conditionnelles, de créer des boucles, de créer des filtres sur les messages entrant/sortant, paramétrer la gestion des erreurs au sein de l'ESB, définir des connexions directement vers des bases de données, même de publier directement sur Twitter. L'ESB est très riche de base, y compris dans sa version libre, et permet de gérer un très grand nombre de cas concrets, que ce soit pour de grandes entreprises ou des PMEs.

Déploiement d'une première application

Veuillez récupérer le zip : Spellchecker sur GitHub.

Dézipper son contenu dans le répertoire MULE_HOME/apps. C'est dans ce répertoire que Mule détecte les applications qu'il doit faire tourner. Nous devons avoir en résultat dans MULE_HOME/apps/Spellchecker/ un lot de fichiers.

Mule devrait détecter automatiquement le changement et déployer directement la nouvelle application.

Spellchecker

But de cette application : à partir d'une requête stockée dans un fichier xml et contenant une phrase quelconque, on va chercher dans une api de google l'ensemble des propositions possibles pour chacun des mots de la phrase et stocker l'ensemble des propositions dans un fichier xml de sortie.

Pour tester, l'application, un peu de paramétrage sera nécessaire :

Dans le fichier mule-config.xml

<flow name="Spell_CheckerFlow1" doc:name="Spell_CheckerFlow1">
<file:inbound-endpoint path=" D:toolsMulestudioMuleStudioexamplesSpellCheckerInXML" responseTimeout="10000" doc:name="Incoming Data File"/>
<echo-component doc:name="Log Info"/>
<http:outbound-endpoint exchange-pattern="request-response" host="www.google.com/tbproxy/spell?lang=en" port="80" doc:name="GOOGLE - SPELL CHECK SERVICE" doc:description="GOOGLE - SPELL CHECK SERVICE"/>
<file:outbound-endpoint path=" D:toolsMulestudioMuleStudioexamplesSpellCheckerOutXML" outputPattern="#[function:datestamp:dd-MM-yy]_#[function:systime].xml" responseTimeout="10000" doc:name="File out" doc:description="File out"/>
</flow>

Créez 2 dossiers dans votre environnement. Le dossier défini dans inbound, sera celui sur lequel notre ESB va lire les fichiers entrants, et celui défini dans outbound contiendra les résultats après traitement par l'api spellcheck de google.

Puis redémarrez l'application Mule.

Posez dans le dossier inbound, le fichier suivant : spellcheck.xml .

Le fichier disparaît quelques secondes après et dans le dossier outbound, se trouve un fichier avec toutes les propositions de google.

A travers le diagramme suivant, on peut visualiser l'enchaînement des traitements effectués par Mule.

  • Mule écoute dans un dossier donné
  • Mule trace le fichier reçu
  • Mule appelle le service de google via l'url  www.google.com/tbproxy/spell?lang=en avec en paramètre la requête contenue dans le fichier entrant
  • Mule récupère la réponse de google et la sauvegarde dans un fichier qu'il archive dans le dossier Outbound

Conclusion

A travers cet article, nous avons fait un premier pas vers les ESB et à travers un exemple particulier, nous sommes parvenus à déployer une première application très simple qui effectue un traitement léger. Bien sur, nous n'avons fait qu'avoir un aperçu de la puissance des ESB.  Plus tard, à travers des exemples plus poussés, nous pourrons voir jusqu'où peuvent aller les ESB.

Les exemples pour l'application Spellcheck sont également disponibles sur github (Explications sur l'utilisation de Git ici : Gestion des versions avec Git )

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.