Enterprise Service Bus

Un article de Wikipédia, l'encyclopédie libre.
Crystal mycomputer.png
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Page d'aide sur l'homonymie Pour les articles homonymes, voir ESB.
ESB

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[1]. Ces "mini-serveurs" contiennent la logique d'intégration et peuvent être déposés n'importe où sur le réseau.

Sommaire

[masquer]

Les principes [modifier]

L'ESB en tant que médiateur entre les clients et les fournisseurs de services s'appuie sur les principes suivants :

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'architecture [modifier]

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.

ArchitectureESB.png

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.

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.

Les cas d'utilisation [modifier]

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.

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)

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.

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.

Les interêts des ESB [modifier]

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.

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.

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.

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.

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.

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 !

Standards [modifier]

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

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.

Notes et références [modifier]

  1. ↑ Enterprise Service Bus, David Chappell
  2. ↑ Définition du Gartner Inc.

Produits propriétaires [modifier]

External.svg
Cet article ou cette section a trop de liens externes.
Les liens externes doivent être des sites de référence dans le domaine du sujet. Il est souhaitable — si cela présente un intérêt — de citer ces liens comme source et de les enlever du corps de l'article ou de la section « Liens externes ».

Produits Libres [modifier]

Liens [modifier]

Ce document provient de « http://fr.wikipedia.org/wiki/Enterprise_Service_Bus ».
Outils personnels
Espaces de noms
Variantes
Actions
Navigation
Contribuer
Autres langues