L'intégration des applications d'entreprise expliquée : les avantages de l'ESB pour l'EAI

Aujourd'hui, l'intégration des systèmes et des applications dans l'infrastructure d'entreprise actuelle est une problématique au centre de toutes les attentions.On en veut pour preuve l'immense variété d'approches et d'idéologies visant à atteindre cet objectif.Lorsque vous commencerez à examiner les différentes solutions d'intégration des données et des applications, vous ne saurez peut-être pas où donner de la tête entre tous les acronymes, les différents avis et un langage marketing parfois déroutant.  

Les avancées rapides en matière de technologie EAI afin de répondre à la multiplication des demandes d'intégration des entreprises suscitent souvent des débats sur ce qu'est ou n'est pas l'EAI ou sur les raisons pour lesquelles les différences négligeables entre deux approches propriétaires en font la seule solution viable.

Dans cet article, nous souhaitons clarifier ce point à l'aide d'un panorama compréhensible et clair de l'évolution de l'EAI.  

Nous commencerons par un bref aperçu des origines de l'EAI, puis nous verrons les avancées majeures dans le domaine de l'architecture EAI et enfin, nous aborderons le remplacement des systèmes EAI traditionnels fondés sur des agents en étoile (hub and spoke) par des architectures ESB fondées sur des normes à la fois agiles et distribuées.

Sommaire

I. Les origines de l'EAI

A. Lorsque l'intégration point à point ne suffit plus

B. L'approche EAI

II. L'EAI traditionnelle

A. Le modèle à agent

B. Avantages et inconvénients

III. ESB : la prochaine étape de l'EAI

A. Principales fonctionnalités

B. Avantages

C. Quand utiliser un ESB

I. Les origines de l'EAI

L'EAI, ou intégration d'applications d'entreprise, existe en tant que terme technique depuis le début des années 2000. Pourtant, la problématique centrale qu'elle cherche à résoudre remonte à beaucoup plus loin.Pour résumer, l'EAI est une approche, ou plus précisément une catégorie générale d'approches, visant à permettre l'interopérabilité entre les multiples systèmes disparates qui forment généralement une infrastructure d'entreprise.

Les architectures d'entreprise sont par nature constituées de nombreux systèmes et applications qui fournissent les différents services sur lesquels s'appuie une entreprise pour fonctionner au quotidien.Une même entreprise peut utiliser des systèmes distincts, développés en interne ou proposés sous licence par un fournisseur tiers, pour gérer sa chaîne logistique, sa relation client, les informations concernant ses employés et sa logique métier.Cette modularisation est souvent souhaitable.En théorie, diviser l'activité d'une entreprise en plusieurs petites fonctionnalités permet d'implémenter facilement les toutes dernières avancées technologiques dans chaque domaine, mais aussi de s'adapter rapidement à l'évolution des besoins métier.  

Toutefois, pour profiter des avantages offerts par ce type de système modulaire et distribué, les entreprises doivent implémenter des technologies capables de traiter les problèmes que présente cette architecture :

• L'interopérabilité : il est possible que les différents composants de l'infrastructure utilisent divers systèmes d'exploitation, formats de données et langages qui empêchent la connexion via une interface standard.
• L'intégration des données : pour qu'un système modulaire et distribué fonctionne, il faut absolument qu'une méthode standard de gestion du flux de données entre les applications et les systèmes assure la cohérence de l'ensemble de la base de données.
• La solidité, la stabilité et l'évolutivité : les solutions d'intégration doivent être particulièrement robustes, stables et évolutives, car elles sont le mortier qui maintient l'ensemble de l'infrastructure modulaire.

Lorsque l'intégration point à point ne suffit plus

Avant l'avènement des approches de type EAI, les problèmes d'intégration étaient souvent traités à l'aide d'intégrations point à point.Dans un modèle d'intégration point à point, un connecteur unique est implémenté pour assurer la communication de chaque paire d'applications ou de systèmes. Ce connecteur gère tous les services liés à la transformation de données, à l'intégration et autres services de messages qui se trouvent entre la paire de composants spécifiques qu'il est conçu pour intégrer.

Utilisé au sein de petites infrastructures où seuls deux ou trois systèmes doivent être intégrés, ce modèle s'avère assez performant puisqu'il fournit une solution d'intégration légère et sur mesure qui répond aux besoins de l'infrastructure.Mais lorsque de nouveaux composants sont ajoutés à l'infrastructure, le nombre de connexions point à point nécessaires à la création d'une architecture d'intégration complète se met à croître de façon exponentielle.

Une infrastructure à trois composants n'a besoin que de trois connexions point à point pour être considérée comme totalement intégrée.Pour avoir un point de comparaison, l'ajout de seulement deux nouveaux composants fait grimper le chiffre à 10 connecteurs.À ce niveau, la complexité atteint déjà un seuil difficile à gérer. Alors, lorsqu'une infrastructure compte 8 ou 9 systèmes et que le nombre de connexions passe à une trentaine, l'intégration point à point ne représente plus du tout une option viable. 

Rappelez-vous que chacun de ces connecteurs doit être développé séparément et qu'il faut en assurer la maintenance à chaque changement de version du système, à chaque évolution et ainsi de suite (ou, dans certains cas, les acheter au prix fort auprès de fournisseurs). Conclusion : l'intégration point à point ne convient absolument pas à un scénario d'entreprise complexe.

L'approche d'intégration EAI

Pour écarter la complexité et les possibilités d'échec liées à l'intégration d'infrastructures complexes à l'aide d'une approche point à point, les solutions EAI utilisent différents modèles middleware pour centraliser et standardiser les pratiques d'intégration sur l'ensemble d'une infrastructure.  

Plutôt que d'avoir recours à des connecteurs qui se connectent à d'autres connecteurs pour chaque application, les composants d'une infrastructure basée sur l'EAI utilisent des méthodes standardisées de connexion à un système commun. Celui-ci se charge de l'intégration, fait office d'agent de messages et garantit la fiabilité pour l'ensemble du réseau.

En d'autres termes, l'EAI résout le problème d'intégration des systèmes modulaires en traitant l'intégration comme n'importe quelle autre tâche, plutôt que comme un enchevêtrement de connexions fragiles.Afin de proposer une solution d'intégration unifiée, les systèmes EAI rassemblent des adaptateurs pour la connectivité, des moteurs de transformation des données pour les convertir au format approprié à l'usage du consommateur, des moteurs d'intégration modulaires qui traitent de nombreux scénarios complexes de routage simultanément et bien d'autres composants.

L'EAI démêle les connexions couplées de l'intégration point à point. Une application peut envoyer un message sans savoir où se trouve le consommateur ni connaître les exigences de données ou la finalité du message. L'implémentation EAI sait traiter toutes ces informations. Cela permet d'obtenir, d'une part, une infrastructure plus flexible où des pièces peuvent être ajoutées ou retirées selon les besoins, en changeant tout simplement la configuration du fournisseur EAI, et d'autre part, un développement modulaire simplifié où un seul service peut être réutilisé par plusieurs applications.

Nombre d'approches EAI modernes tirent également parti de l'opportunité que représente l'ajout d'un mécanisme d'intégration central pour consolider les tâches liées aux messages.Au-delà de l'intégration des données, les EAI modernes proposent parfois des fonctionnalités de gestion de réseau, de sécurité, d'accélération et d'évolutivité pour ne citer qu'elles.

II. L'EAI traditionnelle

Dans les premières solutions EAI commercialisées, le concept d'unification de l'intégration a été appliqué au sens strict, toutes les fonctionnalités nécessaires à l'intégration étant injectées dans un hub centralisé appelé agent.  

Dans cette section, nous allons voir les avantages et les inconvénients de ce modèle afin de comprendre pourquoi il a été abandonné et remplacé par l'architecture ESB. 

Le modèle à agent

Dans cette approche, un moteur d'intégration centralisé appelé agent occupe le centre du réseau d'où il assure la transformation des messages, le routage, ainsi que toute autre fonctionnalité interapplication.Toutes les communications entre applications transitent par le hub afin que celui-ci assure la concomitance des données. 

En général, les implémentations du modèle à agent fournissent aussi des outils d'audit et de surveillance permettant aux utilisateurs d'accéder aux informations concernant le flux de messages transitant sur leurs systèmes, ainsi que des outils visant à accélérer la tâche complexe de configuration du mappage et du routage entre de nombreux systèmes et applications.

Avantages

Comme toutes les approches d'intégration EAI, le modèle à agent permet le couplage libre entre applications.  

Cela signifie que les applications sont capables de communiquer de manière asynchrone. Elles envoient des messages et continuent de fonctionner sans attendre la réponse du destinataire, en sachant exactement de quelle manière le message va atteindre son point de terminaison et, dans certains cas, quel est ce point de terminaison.

Grâce à l'approche à agent, toute la configuration d'intégration est réalisable au sein d'un référentiel centralisé, ce qui limite les configurations à répétition.

Inconvénients

Le risque principal est le même que pour tout autre modèle d'architecture utilisant un moteur centralisé : l'agent peut se transformer en point de défaillance unique pour l'ensemble du réseau.Puisqu'il est responsable de la concomitance des ensembles de données des applications et leurs états, tous les messages entre applications doivent transiter par lui.  

En cas de trafic important, l'agent risque d'agir comme un goulot d'étranglement pour les messages.La destination unique et centralisée du modèle à agent vers laquelle convergent tous les messages pose aussi des problèmes en cas de distances physiques importantes.  

Enfin, les implémentations du modèle à agent sont souvent des produits propriétaires lourds qui prennent uniquement en charge un sous-ensemble de technologies d'un fournisseur spécifique.C'est problématique si votre scénario d'intégration regroupe des produits de plusieurs fournisseurs, des systèmes développés en interne ou des produits legacy n'étant plus pris en charge par le fournisseur.

III. L'ESB : la prochaine étape de l'EAI

Si certaines entreprises ont réussi à implémenter le modèle à agent de l'EAI, la grande majorité des projets d'intégration utilisant ce modèle a fini par échouer.En raison du manque de normes précises pour l'architecture EAI et du caractère propriétaire de la plupart des solutions initiales, les premiers produits EAI étaient coûteux, lourds et avaient tendance à ne pas fonctionner si le système n'était pas suffisamment homogène.  

Et le fait que le modèle à agent transforme le système EAI en point de défaillance unique pour tout le réseau amplifiait ces problèmes.Un composant défectueux pouvait alors entraîner l'arrêt total du réseau.Une étude datant de 2003 estime que 70 % des projets d'intégration ont fini par échouer en raison des défauts des premières solutions à agent.

L'architecture de bus : une nouvelle approche de l'EAI

C'est pour mettre fin aux problèmes engendrés par le hub à agent et l'approche EAI en étoile qu'un nouveau modèle EAI a vu le jour : le bus.Bien que reposant toujours sur un composant de routage centralisé pour transférer les messages d'un système à l'autre, l'architecture de bus visait à alléger la charge fonctionnelle pesant sur ce composant en confiant quelques-unes des tâches d'intégration à d'autres parties du réseau.

Ces composants étaient alors regroupés selon différentes configurations, à l'aide de fichiers de configuration permettant de gérer tous les scénarios d'intégration le plus efficacement possible, et pouvaient être hébergés n'importe où dans l'infrastructure ou dupliqués pour permettre une évolutivité dans de vastes zones géographiques.

La naissance du bus de services d'entreprise

Parallèlement à l'évolution du bus fondé sur l'EAI, le besoin de nouvelles fonctionnalités est apparu : traitement des transactions de sécurité, gestion des erreurs, etc.Alors que dans une architecture à agent, ces fonctionnalités auraient dû être codées en dur dans la logique d'intégration centralisée, l'architecture de bus les incorpore dans des composants séparés.  

Cela permet d'obtenir des solutions d'intégration légères et sur mesure à la fiabilité garantie. Bien séparées de la couche d'application, elles suivent un modèle cohérent et peuvent être conçues et configurées à l'aide d'un minimum de code supplémentaire, sans modifier les systèmes auxquels elles doivent être intégrées.

Cette version mature du modèle d'EAI basé sur le bus s'est finalement imposée sous le nom d'ESB, Enterprise Service Bus ou bus de services d'entreprise.

Principales fonctionnalités de l'ESB

Aujourd'hui, le marché propose toute une variété de produits ESB différents.Certains, comme WebSphere Message Broker ou TIBCO BusinessWorks, sont des produits EAI classiques, refactorisés afin d'offrir des fonctionnalités semblables à l'ESB, bien qu'ils fonctionnent encore sur le principe de l'agent.  

D'autres, comme Mule, la solution ESB de MuleSoft, sont des créations originales, bâties à l'aide de normes ouvertes de messagerie et d'intégration afin d'implémenter le modèle ESB.  

Malgré leurs différences, la plupart des ESB proposent l'ensemble, ou une majorité, des fonctionnalités clés (ou « services ») qui suivent :

• La transparence de lieu : il s'agit d'une méthode permettant la configuration centralisée des points de terminaison des messages, afin que les applications consommatrices n'aient pas besoin de connaître les informations concernant les émetteurs des messages pour recevoir ceux-ci.
• La transformation : il s'agit de la capacité de l'ESB à convertir les messages dans un format utilisable par l'application consommatrice.
• La conversion de protocole : il s'agit d'une exigence semblable à la transformation. L'ESB doit être capable d'accepter les messages envoyés dans tous les principaux protocoles et de les convertir au format dont le consommateur final a besoin. 
• Le routage : il s'agit de la capacité à déterminer le ou les consommateurs finaux appropriés en fonction de règles préconfigurées et de requêtes créées de manière dynamique.
• L'amélioration : il s'agit de la capacité à retrouver des données manquantes dans les messages entrants à partir des données qu'ils contiennent et de les ajouter aux messages avant qu'ils n'atteignent leur destination finale.
• La surveillance/L'administration : l'objectif de l'ESB est de simplifier l'intégration.C'est pourquoi un ESB doit offrir une méthode simple de surveillance des performances du système et du flux de messages qui transite par l'architecture ESB, ainsi qu'un moyen simple pour gérer le système afin de faire bénéficier une infrastructure de la valeur proposée.
• La sécurité : la sécurité de l'ESB repose sur deux composants principaux. Il faut d'abord s'assurer que l'ESB lui-même traite les messages de manière complètement sécurisée et arriver à un compromis entre les différents mécanismes de sécurité utilisés par chacun des systèmes à intégrer.

Les avantages de l'ESB

Voici un aperçu des avantages offerts par une approche ESB de l'intégration d'applications :

• La légèreté : un ESB ne repose pas sur un hub unique contenant l'ensemble des services, mais il se compose de nombreux services qui interagissent. Selon les besoins de l'entreprise, les ESB peuvent donc être lourds ou légers, c'est pourquoi ils constituent la solution d'intégration la plus efficace du marché.
• La facilité d'expansion : si une entreprise sait qu'à l'avenir elle aura besoin de connecter des applications ou des systèmes supplémentaires à son architecture, l'ESB lui permet d'intégrer ses systèmes immédiatement. Elle n'a plus à s'inquiéter de savoir si un système fonctionnera ou non avec son infrastructure existante.Lorsque l'application est prête, il suffit à l'entreprise de la connecter au bus pour qu'elle fonctionne avec le reste de l'architecture.
• Une nature évolutive et distribuable : à l'inverse des architectures à agent, les fonctionnalités de l'ESB sont facilement applicables à l'ensemble d'un réseau couvrant une large zone géographique.Grâce aux composants séparés qui fournissent les différentes fonctionnalités, il est beaucoup plus simple et moins coûteux d'assurer la haute disponibilité et l'évolutivité des aspects essentiels de l'architecture à l'aide d'une solution ESB. 
• La compatibilité SOA : les ESB sont conçus pour s'adapter à l'architecture orientée services (SOA).Cela signifie qu'une entreprise souhaitant migrer vers une SOA peut le faire petit à petit, en continuant d'utiliser ses systèmes existants tout en enfichant des services réutilisables à mesure qu'elle les implémente.
• L'adoption incrémentielle : à première vue, le nombre de fonctionnalités que proposent les meilleures ESB s'avère parfois intimidant.Il vaut donc mieux envisager l'ESB comme une « plateforme » d'intégration dont vous pouvez utiliser seulement les composants qui répondent à vos besoins d'intégration immédiats.Le grand nombre de composants modulaires offre une flexibilité sans précédent qui permet l'adoption progressive d'une architecture d'intégration à mesure que les ressources sont disponibles, tout en garantissant que les besoins pouvant émerger à l'avenir n'entravent pas le retour sur investissement.

Quand utiliser un ESB : prendre des décisions éclairées quant à l'EAI

Toutes les solutions d'intégration présentent des forces et des faiblesses qui dépendent souvent de l'environnement dans lequel elles sont déployées.C'est pourquoi vous devez bien vous renseigner avant de choisir la stratégie EAI qui mènera votre initiative d'intégration au succès.  

Afin que votre démarche EAI et SOA porte ses fruits, il ne suffit pas de choisir la « meilleure » technologie du marché. Il vous faut des éléments concrets sur le scénario d'utilisation pour lequel le produit est prévu, ses performances quelle que soit la charge et sa maturité. Vous devez aussi bien comprendre les défis que votre entreprise doit et devra relever en matière d'intégration.

Avant de prendre une décision en ce qui concerne l'EAI, vous devez avoir une idée bien précise des réponses aux questions suivantes :

• Combien d'applications doivent être intégrées ?  
• À l'avenir, faudra-t-il des applications supplémentaires ?
• Combien de protocoles de communication seront utilisés ?
• Y a-t-il des besoins spécifiques tels qu'un routage, une bifurcation ou une agrégation ?
• Dans quelle mesure l'évolutivité est-elle importante pour mon entreprise ?
• L'intégration requière-t-elle une messagerie asynchrone, des modèles de message pour publier/consommer ou d'autres scénarios de messagerie multiapplications complexes ?

L'article « To ESB or not to ESB », écrit par Ross Mason, fondateur de MuleSoft et architecte initial de la solution ESB Mule, propose un bon aperçu de cette technique aux entreprises qui envisagent une approche d'intégration ESB.Cet article présente une version détaillée de la liste ci-dessus qui vous permettra de savoir si l'ESB convient à vos besoins d'intégration.