Enterprise service bus
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).
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.
Principes
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.
Architecture
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.
L'ESB possède quatre fondements[2] :
- 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.
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.
Cas d'utilisation
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 :
- 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.
Intérêts des ESB
- 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.
Standards
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.
Produits propriétaires
- ESB Blueway de Blueway
- DATA EXCHANGER de Tenor
- NEOFI Link de NEOFI Solutions
- WebSphere Message Broker d'IBM
- InterSystems ENSEMBLE Universal Integration Platform de InterSystems
- le composant ESB de la plate-forme intégrée "Cordys Business Operations Platform" ("Cordys BOP")
- webMethods ESB Platform de Software AG
- Sonic ESB de Aurea software
- SpiritWave de spiritsoft
- ENS Server de Kenamea
- Artix de Iona
- Cape clear de Cape clear
- BizTalk Server de Microsoft
- Oracle Enterprise Service Bus de Oracle Corporation
- iWay SOA Middleware de iWay Software
- Information Builders
- ActiveMatrix Business Works de Tibco Software
- Sybase a aussi une offre ESB
- Fiorano propose une offre complète dans le domaine de l'ESB
- IBM DataPower XI50 utilisant une mémoire flash (passerelle XML) d'IBM, DataPower
- iXBus de SRCI[3]
- SAP PI / PO
- Talend - ESB
Produits libres
- WSO2 Service Bus de WSO2[4]
- Talend ESB de Talend
- JBoss ESB de JBoss
- Mule de Mulesoft
- Open ESB de SUN/Oracle
- Petals ESB de Petals Link, hébergé sur le consortium OW2.
- ServiceMix de la fondation Apache
- Apache Camel décrit comme un ESB léger[5] et qui constitue une brique de ServiceMix.
- SOPERA ESB, de Sopera GmbH.
- Nirva Application Platform
- Zato[6] (Python)
- ESB.Net[7]
- NServiceBus[8]
- Fuse ESB (en)
Voir aussi
Notes et références
- Enterprise Service Bus, David Chappell
- DĂ©finition du Gartner Inc.
- « Accueil - SRCI », sur SRCI (consulté le ).
- (en) « WSO2 Enterprise Service Bus », sur wso2.com (consulté le ).
- « Apache Camel, un framework pour les intégrer tous », sur OCTO Talks !, (consulté le ).
- (en) « Welcome », sur zato.io (consulté le ).
- « CodePlex Archive », sur CodePlex Archive (consulté le ).
- (en) « NServiceBus », sur Particular Software (consulté le ).