L'enterprise service bus (ESB) est une technique informatique intergicielle. Son but est avant tout de permettre la communication des applications qui n'ont pas été conçues pour fonctionner ensemble (par exemple deux progiciels de gestion intégrés provenant d'éditeurs différents).
Principe de l'ESB
Roy Schulte de la société Gartner inc, en fait la description suivante:
«L'ESB est une nouvelle architecture qui exploite les services web, les systèmes orientés messages, le routage intelligent et la transformation. L'ESB agit comme une colonne vertébrale légère et omniprésente de l'intégration à travers laquelle les services logiciels et les composants applicatifs circulent».
L'ESB peut être considérée comme une nouvelle génération d'intégration d'applications d'entreprise (EAI) construite sur des standards comme XML, Java Message Service (JMS) ou encore les services web. La différence majeure avec l'EAI est que l'ESB propose une intégration complètement distribuée grâce à l'utilisation des conteneurs de services[1]. Ces «mini-serveurs» contiennent la logique d'intégration et peuvent être déposés n'importe où sur le réseau.
L'ESB en tant que médiateur entre les clients et les fournisseurs de services s'appuie sur les principes suivants:
La découverte dynamique: les services ainsi que la sémantique associée sont enregistrés dans un annuaire partagé.
La chorégraphie des processus métiers et l'orchestration des services associés: un outil permet d’orchestrer automatiquement les services nécessaires à l’implémentation des processus collaboratifs représentés graphiquement.
La distribution forte: les services sont distribués sur le réseau de l'entreprise ou sur Internet.
La communication par messages: les services s’échangent des messages représentés par des documents textuels.
Le terme ESB a été utilisé la première fois par l'éditeur Sonic Software (filiale Progress Software Corporation). D'une certaine façon les ESB constituent une évolution de l'EAI, notamment pour des raisons de performance en cas de grosses volumétries (les traitements sont potentiellement distribués) et de sécurité (éviter le 'Single Point of failure' potentiel d'une plate-forme centrale), bien que les EAI/ESB les plus récents se soient améliorés sur ces deux problématiques.
L'entreprise service bus possède comme son nom l'indique une architecture en bus qui l'oppose à l'architecture hub and spoke des premiers EAI. Ceci fait de l'ESB une solution hautement distribuée. Les composantes de cette architecture sont illustrées sur la figure suivante.
Le message-oriented middleware (MOM) qui permet l'échange de messages de manière asynchrone. Ainsi chaque message est déposé sur une file d'attente avant d'être consommé par le destinataire.
Les services web qui permettent d'interfacer les applications avec le bus. Chaque service contient une logique d'intégration des messages (transformation, routage, etc.).
Les transformations qui concernent les messages circulant sur le bus, elles sont essentielles dans un ESB car leur rôle est de permettre à des applications de converser même si elles définissent différemment leurs données.
Le routage intelligent qui découple l'expéditeur du message de son destinataire. C'est en fait l'ESB qui va déduire la destination du message. Pour cela il se fonde sur le contenu du message et les règles qui ont été définies.
C’est un cas d’usage limité, presque toujours implémenté avec un ESB Open Source, léger et simple à mettre en œuvre.
On le retrouve dans des applications ayant un fort besoin d’agilité, qui justifie le surcoût en performance que provoque le passage par un ESB, ou dans des applications proposant une interface multi protocoles (pour des progiciels en marque blanche par exemple); le module consommateur de service se trouve alors dans une autre application/système.
Usage tactique
L’utilisation tactique correspond à un ESB utilisé au sein d’une entité / département afin de mettre à disposition pour l’ensemble de l’entité des services réutilisables. Les services exposés peuvent être issus:
De nouvelles applications reposant sur une architecture SOA interne (exposition des services via les standards actuels)
D’applications existantes dont une partie du code applicatif est réutilisé pour exposer des services (exposition des services via les standards actuels)
De systèmes légataires, tels que les mainframes ou AS400 (exposition de services grâce à des connecteurs spécifiques)
Usage stratégique
La vision stratégique correspond à l’utilisation de l’ESB pour établir une communication entre les silos, dans le but d’exposer des services utilisés par des processus métier transverses. Comme pour la vision tactique, les services peuvent être issus de diverses sources, voire de l’ESB tactique qui peut exister dans chacun des silos.
Communication externe
Dans ce cas d’usage, l’ESB est destiné à exposer des services pour une utilisation externe à l’entreprise.
Dans ce genre d’utilisation, les aspects de sécurité doivent être l’objet d’une attention particulière. Pour cette raison, il est d’usage de ne pas utiliser un ESB interne (tactique ou stratégique), mais de dédier un ESB pour les communications avec l’extérieur. Un ESB pour la communication externe sera généralement placé dans une DMZ.
Standardisation des concepts
Les ESB supportent des standards tels que XML, JMS, JCA, JMX et les nombreux standards relatifs aux Web Services. Ce qui implique une intégration des systèmes en place plus rapide, plus économique et plus souple.
Intelligence du routage
Les bus ESB automatisent le routage des transactions commerciales en fonction du contenu des documents XML et des règles commerciales établies. Il n’est ainsi plus nécessaire de programmer cette fonctionnalité dans le code de l’application.
Architecture de services
Les fonctionnalités fournies par les ESB sont implémentées comme des services spécialisés distincts (service de transformation, service de routage intelligent, service de logging…). Ces services implémentés dans de petits containers peuvent être déployés indépendamment les uns des autres, de façon sélective.
Architecture distribuée
L’architecture de services des ESB est distribuée avec beaucoup plus de modularité qu’une architecture monolithique, ce qui permet d’apporter une réponse précise et souple aux besoins de scalabilité rencontrés dans les problématiques de montée en charge.
Fiabilité
Les ESB permettent de construire des architectures sans point individuel de défaillance (SPOF). Ainsi, quand un serveur tombe en panne, le reste du système peut continuer à fonctionner.
Souplesse de déploiement
Les bus ESB offrent la possibilité de centraliser les services de configuration, de déploiement et de gestion distribués à l’échelle de l’entreprise. De plus, il permet d'échelonner et gérer les services de l’entreprise indépendamment les uns des autres. La transparence des implantations permet de mettre les services à niveau, de les déplacer ou de les remplacer sans avoir à changer le code.
Le standard JBI est important, mais n'emporte pas l'adhésion de tous les acteurs (IBM et BEA notamment). Pour cette raison, les éditeurs proposent souvent leur propre conteneur de services.
