Un ESB, ou Enterprise Service Bus, est un modèle d’architecture dans lequel un composant logiciel centralisé assure des intégrations entre les applications.  Il s’occupe de la transformation des modèles de données, de la connectivité, du routage des messages, de la conversion des protocoles de communication et potentiellement de la composition de plusieurs requêtes. L’ESB peut rendre ces intégrations et transformations disponibles en tant qu’interface de service à réutiliser dans de nouvelles applications. 

Le modèle ESB est généralement mis en oeuvre à l’aide d’un ensemble d’outils et d’un runtime d’intégration spécialement conçus (c’est-à-dire, un produit ESB) qui garantissent la meilleure productivité possible.

Un ESB est un composant essentiel de la SOA (ou architecture orientée services), une architecture logicielle apparue à la fin des années 90. La SOA définit un moyen de rendre les composants logiciels réutilisables par le biais d’interfaces de service. Ces services utilisent généralement des interfaces standard (c’est-à-dire, des services Web) afin de pouvoir les intégrer rapidement à de nouvelles applications sans avoir à dupliquer les fonctionnalités exécutées par le service dans de nouvelles applications.

Chaque service d’une SOA comporte le code et les données nécessaires pour exécuter une fonction métier complète et discrète (par exemple, vérifier le crédit d’un ou d’une client(e), calculer les mensualités d’un prêt ou traiter une demande de prêt hypothécaire). Les interfaces de service fournissent un couplage lâche, ce qui signifie qu’il est possible de leur faire appel même si elles possèdent peu ou pas de connaissances sur l’implémentation du service en dessous, réduisant ainsi les dépendances entre les applications. Les applications derrière l’interface de service peuvent être codées avec les langages de programmation Java, Microsoft .NET, Cobol ou autre, fournies sous forme de packages d’applications d’entreprise par un fournisseur (par exemple, SAP), d’applications SaaS (par exemple, Salesforce CRM), ou obtenues en tant qu’applications open source.  

Les interfaces de service sont fréquemment définies à l’aide du langage WSDL (Web Service Definition Language), une structure de balises standard basée sur le XML (Extensible Markup Language).  Les services sont exposés à l’aide de protocoles réseau standard, comme SOAP (Simple Object Access Protocol)/HTTP ou JSON/HTTP, pour envoyer des demandes de lecture ou de modification de données. La gouvernance des services contrôle le cycle de vie pendant le développement et, à l’étape appropriée, les services sont publiés dans un registre qui permet aux développeurs de les trouver rapidement et de les réutiliser pour assembler de nouvelles applications ou de nouveaux processus métier.

Les services peuvent être créés de toutes pièces, mais ils sont souvent créés en exposant les fonctions d’anciens systèmes d’enregistrement. Les entreprises peuvent choisir de fournir une interface de service basée sur des normes en avant des anciens systèmes, d’utiliser l’ESB pour se connecter directement au système existant via un adaptateur ou un connecteur, ou l’application peut fournir sa propre API. Dans tous les cas, l’ESB protège la nouvelle application de l’interface existante. Un ESB effectue les opérations de transformation et de routage nécessaires pour se connecter au service du système existant.

Il est possible de mettre en œuvre une SOA sans architecture ESB, mais cela reviendrait à disposer simplement de plusieurs services. Chaque propriétaire d’application devrait se connecter directement au service dont il a besoin et effectuer les transformations de données nécessaires pour répondre à chacune des interfaces de service. Cela représente une charge de travail importante (même si les interfaces sont réutilisables) et crée des défis de maintenance significatifs pour la suite, car chaque connexion s’effectue point-à-point.

En théorie, un ESB centralisé offre la possibilité de normaliser et de simplifier considérablement la communication, la messagerie et l’intégration entre les services de l’entreprise. Les coûts matériels et logiciels peuvent être partagés, en mettant à disposition les serveurs nécessaires pour une utilisation combinée, ce qui permet de fournir une solution centralisée évolutive.  Une seule équipe de spécialistes peut être chargée de développer et de maintenir les intégrations (et, si nécessaire, être formée à le faire).

Les applications logicielles se connectent simplement (« parlent ») à l’ESB et laissent à ce dernier le soin de transformer les protocoles, d’acheminer les messages et de les convertir dans les formats de données requis, garantissant ainsi l’interopérabilité nécessaire à l’exécution des transactions. L’approche architecturale de l’Enterprise Service Bus prend en charge les scénarios d’intégration des applications, d’intégration des données et d’automatisation des processus métier sous forme d’orchestration des services.  Les développeurs peuvent ainsi consacrer nettement moins de temps à l’intégration et beaucoup plus de temps au déploiement et à l’amélioration de leurs applications. En outre, la possibilité de réutiliser ces intégrations d’un projet à l’autre offrait potentiellement des gains de productivité et des économies en aval encore plus importants.

Toutefois, si les ESB ont été déployés avec succès dans de nombreuses entreprises, ils représentent pour tout autant d’autres un goulot d’étranglement. Apporter des modifications ou des améliorations à une intégration pourrait en déstabiliser d’autres qui utilisent cette même intégration. Les mises à jour du middleware ESB avaient souvent un impact sur les intégrations existantes. Pour effectuer une mise à jour, il était donc nécessaire de réaliser des tests approfondis. L’ESB étant géré de manière centralisée, les équipes d’application se sont rapidement retrouvées à devoir attendre leurs intégrations. À mesure que le volume des intégrations augmentait, assurer une haute disponibilité et une reprise après sinistre pour les serveurs ESB devenait de plus en plus coûteux. En tant que projet à l’échelle de l’entreprise, l’ESB s’est avéré difficile à financer, ce qui a d’autant plus complexifié la résolution de ces difficultés techniques.

En fin de compte, les difficultés liées à la maintenance, à la mise à jour et à la mise à l’échelle d’un ESB centralisé se sont révélées si écrasantes et si coûteuses que l’ESB a souvent retardé les gains de productivité que lui et la SOA étaient censés apporter, suscitant ainsi un sentiment de frustration au sein des équipes commerciales qui s’attendaient à un rythme d’innovation plus soutenu.

Pour une analyse plus approfondie de l’ascension et du déclin de l’ESB, lisez « Le destin de l’ESB » (en anglais).

L’architecture de microservices permet de diviser les composants internes d’une seule application en petits morceaux qui peuvent être modifiés, mis à l’échelle et gérés de manière indépendante. Les microservices sont apparus et ont pris de l’ampleur avec l’essor de la virtualisation, du cloud computing, des pratiques de développement Agile et de DevOps. Dans de tels contextes, les microservices offrent les avantages suivants :

• Une amélioration de l’agilité et de la productivité des développeurs en leur permettant d’intégrer de nouvelles technologies dans une partie d’une application sans devoir modifier ni « rattraper » le reste de l’application. 
• Une évolutivité plus simple et plus rentable grâce à la possibilité de faire évoluer n’importe quel composant indépendamment des autres, afin de répondre le plus rapidement possible aux exigences de charge de travail et d’utiliser les ressources informatiques de la manière la plus efficace qui soit.
• Une plus grande résilience, car la défaillance d’un composant n’a pas d’incidence sur les autres. De plus, chaque microservice peut fonctionner selon ses propres exigences en matière de disponibilité sans que les autres composants ne soient soumis à une exigence de « plus grande disponibilité commune ».

Il est possible d’apporter à l’intégration la même granularité que les microservices apportent à la conception d’applications, et ce avec des avantages similaires. C’est l’idée derrière l’intégration agile, qui décompose l’ESB en composants d’intégration précis et décentralisés, sans interdépendances, que les équipes d’application individuelles peuvent détenir et gérer elles-mêmes.