MuleSoft - Le projet Mule

Les motivations du projet Mule étaient -

• pour simplifier les choses pour les programmeurs,

• le besoin d'une solution légère et modulaire qui pourrait évoluer d'un cadre de messagerie au niveau de l'application à un cadre hautement distribuable à l'échelle de l'entreprise.

Mule ESB est conçu comme un cadre événementiel et programmatique. Il est piloté par les événements car il est combiné avec une représentation unifiée des messages et peut être extensible avec des modules enfichables. Il est programmatique car les programmeurs peuvent facilement implémenter certains comportements supplémentaires tels que le traitement de messages spécifiques ou la transformation de données personnalisée.

L'histoire

La perspective historique du projet Mule est la suivante -

Projet SourceForge

Le projet Mule a été lancé en tant que projet SourceForge en avril 2003, et après 2 ans, sa première version a été publiée et déplacée vers CodeHaus. L'API UMO (Universal Message Object) était au cœur de son architecture. L'idée derrière l'API UMO était d'unifier la logique tout en les isolant des transports sous-jacents.

Version 1.0

Il a été publié en avril 2005 contenant de nombreux transports. Le principal objectif de nombreuses autres versions suivies était le débogage et l'ajout de nouvelles fonctionnalités.

Version 2.0 (adoption du printemps 2)

Spring 2 comme cadre de configuration et de câblage a été adopté dans Mule 2 mais il s'est avéré être une révision majeure en raison du manque d'expressivité de la configuration XML requise. Ce problème a été résolu lorsque la configuration basée sur le schéma XML a été introduite dans Spring 2.

Construire avec Maven

La plus grande amélioration qui a simplifié l'utilisation de Mule, à la fois au moment du développement et du déploiement, a été l'utilisation de Maven. À partir de la version 1.3, il a commencé à être construit avec Maven.

MuleSource

En 2006, MuleSource a été incorporé «pour aider à soutenir et permettre à la communauté en croissance rapide d'utiliser Mule dans des applications d'entreprise critiques». Cela s'est avéré être le jalon clé du projet Mule.

Concurrents de Mule ESB

Voici quelques-uns des principaux concurrents de Mule ESB -

• WSO2 ESB
• Oracle Service Bus
• Agent de messages WebSphere
• Plateforme Aurea CX
• Fiorano ESB
• WebSphere DataPower Gateway
• Cadre de processus d'entreprise Workday
• Bus de service d'entreprise Talend
• Bus de service d'entreprise JBoss
• Gestionnaire de service iWay

Concept de base de Mule

Comme indiqué précédemment, Mule ESB est une plate-forme d'intégration et de bus de services d'entreprise Java légère et hautement évolutive. Indépendamment des diverses technologies utilisées par les applications, Mule ESB permet une intégration facile des applications, leur permettant d'échanger des données. Dans cette section, nous discuterons du concept de base de Mule entrant en jeu pour permettre une telle intégration.

Pour cela, nous devons comprendre son architecture ainsi que ses éléments constitutifs.

Architecture

L'architecture de Mule ESB comporte trois couches à savoir, la couche de transport, la couche d'intégration et la couche d'application, comme indiqué dans le diagramme suivant -

En règle générale, trois types de tâches peuvent être effectuées pour configurer et personnaliser le déploiement de Mule:

Développement de composants de service

Cette tâche implique le développement ou la réutilisation des POJO existants, ou Spring Beans. POJOs est une classe avec des attributs qui génère les méthodes get et set, les connecteurs cloud. D'autre part, Spring Beans contient la logique métier pour enrichir les messages.

Orchestration des services

Cette tâche fournit essentiellement la médiation de service qui implique la configuration du processeur de messages, des routeurs, des transformateurs et des filtres.

L'intégration

La tâche la plus importante de Mule ESB est l'intégration de diverses applications quels que soient les protocoles qu'elles utilisent. À cette fin, Mule fournit des méthodes de transport qui permettent de recevoir et d'envoyer les messages sur différents connecteurs de protocole. Mule prend en charge de nombreuses méthodes de transport existantes, ou nous pouvons également utiliser une méthode de transport personnalisée.

Blocs de construction

La configuration Mule comprend les blocs de construction suivants -

Haricots de printemps

L'utilisation principale des beans Spring est de construire un composant de service. Après avoir construit le composant de service Spring, nous pouvons le définir via un fichier de configuration ou manuellement, au cas où vous n'auriez pas de fichier de configuration.

Agents

Il s'agit essentiellement d'un service créé dans Anypoint Studio avant Mule Studio. Un agent est créé une fois que vous démarrez un serveur et sera détruit une fois que vous arrêtez le serveur.

Connecteur

Il s'agit d'un composant logiciel configuré avec les paramètres spécifiques aux protocoles. Il est principalement utilisé pour contrôler l'utilisation d'un protocole. Par exemple, un connecteur JMS est configuré avec unConnection et ce connecteur sera partagé entre différentes entités en charge de la communication proprement dite.

Configuration globale

Comme son nom l'indique, ce bloc de construction est utilisé pour définir les propriétés et les paramètres globaux.

Points de terminaison mondiaux

Il peut être utilisé dans l'onglet Éléments globaux qui peut être utilisé autant de fois dans un flux -

Processeur de messages global

Comme son nom l'indique, il observe ou modifie un message ou un flux de messages. Les transformateurs et les filtres sont des exemples de Global Message Processor.

Transformers- Le travail principal d'un transformateur est de convertir des données d'un format à un autre. Il peut être défini globalement et peut être utilisé dans plusieurs flux.

Filters- C'est le filtre qui décidera quel message Mule doit être traité. Le filtre spécifie essentiellement les conditions qui doivent être remplies pour qu'un message soit traité et acheminé vers un service.

Des modèles

Contrairement aux agents, il s'agit d'un regroupement logique de services qui sont créés en studio. Nous avons la liberté de démarrer et d'arrêter tous les services à l'intérieur d'un modèle spécifique.

Services- Les services sont ceux qui englobent notre logique métier ou nos composants. Il configure également les routeurs, les points de terminaison, les transformateurs et les filtres spécifiquement pour ce service.

Endpoints- Il peut être défini comme un objet sur lequel les services recevront des messages entrants (recevoir) et sortants (envoyer). Les services sont connectés via des points de terminaison.

Couler

Le processeur de messages utilise des flux pour définir un flux de messages entre une source et une cible.

Structure des messages Mule

Un message Mule, totalement enveloppé sous Mule Message Object, sont les données qui transitent par les applications via les flux Mule. Le message de la structure Mule est illustré dans le diagramme suivant -

Comme le montre le diagramme ci-dessus, Mule Message se compose de deux parties principales -

Entête

Ce ne sont rien d'autre que les métadonnées du message qui sont en outre représentées par les deux propriétés suivantes -

Inbound Properties- Ce sont les propriétés qui sont automatiquement définies par la source du message. Ils ne peuvent pas être manipulés ou définis par l'utilisateur. Dans la nature, les propriétés entrantes sont immuables.

Outbound Properties- Ce sont les propriétés qui contiennent des métadonnées comme une propriété entrante et qui peuvent être définies au cours du flux. Ils peuvent être définis automatiquement par Mule ou manuellement par un utilisateur. Dans la nature, les propriétés sortantes sont modifiables.

Les propriétés sortantes deviennent des propriétés entrantes lorsque le message passe du point de terminaison sortant d'un flux au point de terminaison entrant d'un flux différent via un transport.

Les propriétés sortantes restent des propriétés sortantes lorsque le message est passé à un nouveau flux via une référence de flux plutôt qu'un connecteur.

Charge utile

Le message commercial réel transporté par l'objet de message est appelé charge utile.

Variables

Il peut être défini comme les métadonnées définies par l'utilisateur sur un message. Fondamentalement, les variables sont des informations temporaires sur un message utilisé par l'application qui le traite. Il n'est pas destiné à être transmis avec les messages à sa destination. Ils sont de trois types comme indiqué ci-dessous -

Flow variables - Ces variables s'appliquent uniquement au flux dans lequel elles existent.

Session variables - Ces variables s'appliquent à tous les flux d'une même application.

Record variables - Ces variables s'appliquent uniquement aux enregistrements traités dans le cadre d'un lot.

Pièces jointes et charge utile supplémentaire

Ce sont des métadonnées supplémentaires sur la charge utile du message qui n'apparaissent pas nécessairement à chaque fois dans l'objet message.