Enterprise Service Bus

L'Enterprise Service Bus ou ESB est une technique informatique intergicielle. Son but est avant tout de permettre la communication des applications qui à la base ne sont pas pensées pour fonctionner ensemble (deux ERP - Enterprise Resource Planning ou Progiciel de gestion intégré - provenant de deux éditeurs différents par exemple).

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".

On peut considérer l'ESB comme une nouvelle génération d'EAI (en français, Intégration d'applications d'entreprise) construite sur des standards comme XML, JMS ou encore les services web. Aussi, la différence majeure avec l'EAI réside dans le fait que l'ESB propose une intégration complètement distribuée grâce à l'utilisation des conteneurs de services. 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'Enterprise 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.

• L'ESB possède quatre fondements :

Le Middleware Orienté Message (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 base sur le contenu du message et les règles qui ont été définies.

• Peuvent venir se greffer à cette architecture:

Le Business Activity Monitoring (BAM) qui permet de suivre l'activité d'un processus métier.

Le Business Process Management (BPM) qui a pour but de maîtriser l'orchestration des processus métier, c'est-à-dire l'enchaînement des échanges entre applications.

• Usage intra-applicatif

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 :

1. De nouvelles applications reposant une sur une architecture SOA interne (exposition des services via les standards actuels)
2. D’applications existantes dont une partie du code applicatif est réutilisé pour exposer des services (exposition des services via les standards actuels)
3. 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 même 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.

• L’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.

• Une 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, etc.). 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.

• Une 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.

• La souplesse du 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 vous autorise à é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 devoir changer une ligne de code !

L'ESB peut s'appuyer sur les standards suivants :

• JMS pour le bus.
• SOAP, WSDL, UDDI pour les services Web.
• JBI pour les conteneurs de services.
• XML, XSLT, XPath pour la transformation et le routage.
• JCA pour la connexion aux applications.
• BPEL pour l'orchestration des processus métier.

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.

• Aqualogic Service Bus de BEA (Acheté par Oracle en Janvier 2008)
• WebSphere Application Server V6 d'IBM
• InterSystems ENSEMBLE Universal Integration Platform de InterSystems
• webMethods ESB Platform de Software AG
• Sonic ESB de Progress Software
• SpiritWave de spiritsoft
• ENS Server de Kenamea
• Artix de Iona
• Cape clear de Cape clear
• BizTalk Server de Microsoft
• Mule ESB de Mulesoft
• Oracle Enterprise Service Bus de Oracle Corporation
• iWay SOA Middleware de iWay Software, une société de
• Information Builders
• TIBCO BusinessWorks™
• Sybase a aussi une offre ESB.
• Fiorano propose une offre complète dans le domaine de l'ESB
• Nirva Application Platform de Nirva Systems
• IBM DataPower XI50 utilisant une mémoire flash (passerelle XML) d'IBM, DataPower

• JBoss ESB de JBoss
• Mule, de Mulesoft
• Open ESB, de SUN/Oracle
• ESB de Petals Link, hébergé sur le consortium OW2.
• Servicemix de la fondation Apache
• SOPERA ESB, de Sopera GmbH.