Qu'est-ce qu'un ESB ?

En substance, un bus de services d'entreprise (ESB, Enterprise Service Bus) est une architecture. Il se compose d'un ensemble de règles et de principes permettant d'intégrer de nombreuses applications au sein d'une infrastructure de type bus. Les produits ESB permettent aux utilisateurs de construire ce type d'architecture, mais présentent des différences dans les approches utilisées pour le faire et les capacités offertes. Le concept qui sous-tend l'architecture ESB consiste à intégrer différentes applications en plaçant entre elles un bus de communication, puis en autorisant chaque application à communiquer avec celui-ci. Ainsi, vous découplez les systèmes les uns des autres et leur permettez de communiquer sans dépendre, ou avoir connaissance, des autres systèmes présents sur le bus. Le concept d'ESB est né du besoin d'abandonner l'intégration point à point qui se fragilise avec le temps et s'avère difficile à gérer. L'intégration point à point provoque la prolifération de code d'intégration personnalisé dans diverses applications, sans aucun moyen centralisé de gestion ni de dépannage. Souvent appelé « code spaghetti », celui-ci n'offre aucune évolutivité, car il crée de fortes dépendances entre les applications.

L'une des principales raisons pour lesquelles les entreprises choisissent de mettre en place une architecture ESB pour structurer leur infrastructure IT est qu'elle améliore leur agilité en réduisant les délais de commercialisation pour leurs nouvelles initiatives. Une architecture ESB facilite cette démarche en proposant un système simple, bien défini et « enfichable » à l'évolutivité exceptionnelle. De plus, grâce aux capacités de communication et de transformation de l'ESB, vous exploitez vos systèmes existants et les exposez à de nouvelles applications.

L'architecture ESB repose sur certains principes clés à l'origine de l'agilité et de l'évolutivité métier. L'accent est principalement mis sur le découplage des systèmes et leur capacité à communiquer de manière cohérente et facile à gérer.

• Le concept de « bus » permet de découpler les applications les unes des autres. On utilise généralement pour cela un serveur de messagerie de type JMS ou AMQP.
• Les données transitent par le bus dans un format canonique, presque toujours XML.
• Un « adaptateur » placé entre l'application et le bus guide les données entre les deux parties.
• Le rôle de cet adaptateur est de communiquer avec l'application back-end et de transposer les données du format de l'application à celui du bus. L'adaptateur peut aussi exécuter d'autres tâches, liées notamment à la gestion, à la sécurité, à la surveillance ou au traitement des erreurs concernant les transactions de routage des messages.
• Les ESB ne présentent généralement pas d'état, ce dernier étant intégré aux messages qui transitent par le bus.
• Le format de message canonique correspond au contrat entre les systèmes. Ce format canonique assure la cohérence du format de message qui transite par le bus et permet à toutes les applications du bus de communiquer entre elles.

Découvrons maintenant comment l'architecture ESB s'aligne sur nos cinq principes d'intégration fondamentaux :

• Orchestration : il s'agit de réunir plusieurs composants existants dédiés à une seule tâche en un service composite unifié de niveau supérieur. Cela permet d'obtenir la granularité de services désirée et de faciliter la réutilisation et la gestion des composants sous-jacents.
• Transformation : il s'agit de la transformation des formats de données canoniques en format de données spécifiques correspondant à chaque connecteur ESB. Pour illustrer cela, on citera par exemple la transformation d'un format CSV, copybook COBOL ou EDI en un format SOAP/XML ou JSON. Les formats de données canoniques simplifient grandement les exigences de transformation pour une importante implémentation ESB qui englobe de nombreux consommateurs et fournisseurs possédant chacun leurs propres formats et définitions de données.
• Transport : il s'agit de la négociation du protocole de transport entre différents formats (comme HTTP, JMS, JDBC). Remarque : Mule traite les bases de données comme n'importe quel autre « service » en utilisant le format JDBC comme moyen de transport (ou point de terminaison) où les données seront accessibles.
• Médiation : il s'agit de la mise à disposition de plusieurs interfaces dans le but a) de prendre en charge plusieurs versions d'un service pour assurer la compatibilité avec les versions antérieures, ou b) de permettre l'utilisation de plusieurs canaux pour la même implémentation de composants sous-jacents. Cette seconde exigence peut impliquer l'utilisation de plusieurs interfaces pour un même composant : une interface legacy (fichier plat) et une interface conforme aux normes (SOAP/XML).
• Cohérence non fonctionnelle : il s'agit notamment, dans le cadre d'une initiative ESB classique, de la cohérence dans la manière dont sont appliquées et implémentées les politiques de surveillance et de sécurité. Il est par ailleurs possible d'atteindre les objectifs d'évolutivité et de disponibilité à l'aide de plusieurs instances d'ESB afin d'augmenter le rendement (évolutivité) et d'éliminer les points de défaillance unique (SPOF), ce qui constitue l'objectif principal des systèmes haute disponibilité.

Il existe de nombreuses plateformes ESB, qu'il s'agisse de celles proposées par d'importants fournisseurs propriétaires ou par des fournisseurs plus spécifiques et open source. Sur le papier, elles se ressemblent beaucoup. Voici quelques points à prendre en compte au moment de faire votre choix.

Mule est la plus légère des plateformes d'intégration du marché avec seulement 40 Mo pour une distribution entièrement chargée. Sa conception modulaire vous permet d'écarter les modules qui ne vous intéressent pas lorsque vous recherchez un encombrement minimal. La légèreté n'est pas qu'une question de taille, c'est aussi une question de coûts relatifs aux changements à apporter aux intégrations existantes et aux efforts que ces derniers nécessitent. Le runtime Mule offre des capacités de modularisation et un déploiement à chaud ultrarapide, sans oublier un modèle de configuration qui facilite la réorganisation, l'ajout et le remplacement des fonctionnalités.

La plupart des fournisseurs conçoivent un ESB comme une simple médiation entre systèmes et proposent donc des produits distincts pour héberger la logique métier et publier les services. Nous pensons que cette complexité est inutile. Mule vous propose un conteneur de services léger et évolutif pour publier des services REST et SOAP. Et puisque Mule s'intègre étroitement avec Spring, les développeurs peuvent aussi exploiter les capacités de Spring pour implémenter la logique métier.

Mule repose sur des outils répandus que tous les développeurs Java connaissent tels que Maven, Eclipse, JUnit et Spring. Mule utilise un modèle de configuration XML (similaire à Spring) pour définir la logique. Il est possible de rédiger du code personnalisé dans différents langages, notamment Java, Groovy, JavaScript, Ruby ou encore Python. Et grâce à son environnement de développement graphique, Anypoint Studio offre une prise en main rapide à tous les nouveaux développeurs.

Mule a été conçu pour une évolutivité horizontale sur un équipement de base. Vous n'aurez donc pas besoin de machines sophistiquées. Le runtime Mule est facile à intégrer dans une application. Il peut aussi être intégré dans votre serveur d'applications comme Tomcat, JBoss ou WAS, ou bien directement dans votre application. Et surtout, Mule prend en charge JUnit, ce qui signifie qu'il peut être intégré dans un scénario de test JUnit. Cela vous permet de créer des tests unitaires réplicables pour les intégrations, exécutables sur l'ordinateur portable d'un développeur et intégrables à un processus de conception continue.

L'indépendance du conteneur vis-à-vis des messages est sans doute l'une des fonctionnalités les plus intéressantes de Mule. Cela signifie qu'il n'impose pas les messages XML à ses utilisateurs. Certes, le format XML est très courant, mais dans certaines situations, vous préférerez peut-être utiliser un format JSON, des fichiers plats, des copybooks COBOL, un format binaire et des pièces jointes, des flux ou encore des objets Java. Notre outil de mappage de données graphiques est tout aussi ouvert vis-à-vis du type de données pouvant être mappées. Dernier avantage, le flux de diffusion Mule permet aux développeurs de traiter efficacement les messages lourds.

Si vous préférez confier l'architecture d'application, l'hébergement et la surveillance de votre intégration aux experts du domaine, alors CloudHub™ est fait pour vous. CloudHub est une plateforme d'intégration en tant que service (iPaaS) opérationnelle en quelques minutes. Cette plateforme mutualisée et élastique offre une connectivité avec plus de 150 SaaS, réseaux sociaux et services d'infrastructure, et vous permet de connecter vos applications on-prem. Les applications CloudHub s'exécutent de manière autonome sur Mule et vice versa. Par conséquent, que votre déploiement soit on-prem ou dans le cloud, vous n'aurez pas besoin de maîtriser de nouveaux concepts et l'expérience de développement restera identique. Pas besoin de changer de manière de travailler.

La plupart des entreprises souhaitent accroître leur agilité en réduisant le délai de commercialisation de leurs nouvelles initiatives. Les ESB les aident dans cette démarche grâce à l'implémentation d'un système simple, bien défini et « enfichable » à l'évolutivité exceptionnelle. Chez MuleSoft, nous savons qu'une architecture ESB doit jouer le rôle d'une véritable architecture et ne pas être un simple produit de plus. Il ne s'agit pas uniquement d'infrastructure, mais également de conception d'applications.

Découvrez la solution ESB la plus flexible au monde, Mule, le moteur runtime d'Anypoint Platform, et la manière dont il aide les entreprises à construire une architecture basée sur l'agilité et la vitesse.