NB : cet article fait partie d’une série de présentation et de tutoriaux pour démystifier Mule ESB : http://net-progress.blogspot.com/)
Mule est un framework de messagerie basé sur une architecture EDA et mettant en ouvre les principes d’intégration du fameux livre Enteprise Integration Patterns by Gregor Hohpe et Bobby Woolf.
Le cœur du système est le bus de message, qui route les messages entre les applications.
La version 2.x de Mule a innové dans le sens où elle n’a pas suivi l’approche classqiue des ESB/EAI qui consiste à convertir systématiquement tout message transitant dans le Bus en un format pivot. Mule convertit seulement les données qui sont nécessaires.
Mule n’exige pas l’usage d’un seul format commun de message et la nécessité d’adaptateurs pour convertir du format de l’application cible vers le format pivot..
L’information est envoyée sur un canal de communication, comme HTTP ou JMS, et est transformée seulement si nécessaire au cours du traitement.
Ainsi, Mule améliore les performances et réduit les coûts de développement par rapport à un ESB traditionnel.
Au niveau le plus simple, quand on connecte les applications à Mule, il lit les données venant d’une application, les transforme si c’est nécessaire pour que l’application cible puisse les lire, et les envoie vers une autre application.
Un message est simplement un paquet de données manipuler et envoyer entre les applications sur un spécifique channel (aussi appelée une queue).
Intégration de Mule
· Les composants MuleESB
o Les connectors
o Le container léger Spring
o Les routers
o Les transformers
Quand un message est envoyé par une application (comme la facture par Order Entry ) , Mule relève le message, l’envoie à un service qui le traite avec sa logique métier (comme la vérification du client, l’inventaire des données en bases), et ensuite le route correctement vers une autre application (comme l’application Order Fulfillment). Mule contient plusieurs parties qui gère le traitement et le routage des messages.
La part principale du service est le service component. Le service component exécute la logique métier sur les messages, comme lire l’objet Facture, lui ajouter des informations qui provient de la base données clients, et ensuite le forwarder vers l’application Order Fullfillment.
Un point important est que le service component ne contient pas de code spécifique Mule ; il peut être un simple objet Java POJO, un bean Spring, ou un web service contenant la logique métier pour traiter les données de façon spécifique.
Mule gère le service component, le lie à une configuration et l’expose comme un service, et s’assure que l’information qui lui est envoyée est correcte ceci en se basant sur les informations du service que l’on a spécifié dans le fichier de configuration de Mule.
- Le service component contient la logique métier pour traiter les données dans le message. Il ne contient aucune information sur comment est reçu ou sont envoyés les messages eux mêmes.
-
- Pour être sur que le service component reçoit le bon message et le route correctement après traitement, on spécifie lors de la configuration de Mule un inbound router et un outbound router qui encapsule le service component.
-
- Un Inbound router spécifie quels messages le composant service va traiter. Il peut filtrer les messages entrants, les agréger ou les re-séquencer avant de les router vers un autre service component. Par exemple, si un service souscrit à un fil RSS, le inbound router peut filtrer quels messages recevoir sur ce fil.
-
- Après qu’un service est traité un message, le outbound router spécifie où dispatcher le message. On peut définir de multiples contraintes de routages entrant et sortant et même chaîner des routeurs ensembles de telle façon qu’un service component reçoivent et routent les messages exactement comme requis.
Multi protocoles
-Mule peut gérer des messages qui sont envoyés par de nombreux protocoles.
Par exemple, si une facture peut toujours être au format XML, elle peut arriver par HTTP dans un cas et dans un message JMS dans l’autre, cela dépend de quelle application a créée la facture.
- le service component ne sait pas comment lire les messages parce que par défaut les services components sont indépendants du format du message.
A la place, un composant transport apporte le message et des transformers change l’objet du message dans un format compréhensible par le service component avant que le routeur ne lui transmette. Par exemple, si une facture xml est envoyé par http, le http transporte le message, les routeurs envoient le message à chaque service qui doivent le traiter, et les transformers change la facture du xml en objet comme attendu par le service.
Transparence
-Tout le transport, les transformations, et le routage du message sont complètement transparent pour le service component.
Les transformers sont essentiels pour échanger des données, parce qu’ils permettent à Mule de convertir les données dans un format compréhensible par un autre composant ou une autre application. Plus important, les données sont transformées seulement si besoin. A la place de convertir tous les messages dans un format commun, les messages et leurs données sont transformés seulement si pour le composant ou l’application cible, c’est nécessaire.
Changer le protocole d’accès sans toucher au métier
-Enfin, on peut utiliser différents types de transport pour gérer différents canaux, comme envoyer le message sur du HTTP et ensuite le forwarder sur du JMS après qu’il ait été traité par le service Customer Data Component.
- La séparation de la logique métier de l’envoi et de la transformation des messages permet une grande flexibilité dans la mise en place de l’architecture et fait que c’est plus simple de modifier la logique métier sans avoir à se soucier des divers formats dans lequel le message peut arriver.
OCR et numérisation
Articles
