Rôle d’un ESB dans un

environnement SOA
Résumé analytique
La souplesse opérationnelle — la capacité de s’adapter rapidement à des besoins
changeants — devient un objectif de plus en plus essentiel pour les entreprises
opérant sur le marché mondial très concurrentiel. Les directeurs opérationnels ont
besoin d’une reconfiguration rapide des ressources et des processus pour effectuer
ces changements. Pour faciliter ces derniers, les directions informatiques examinent
des façons d’associer des applications et de fournir des fonctions métier pouvant être
transformées en services et réutilisées dans toute l’entreprise.

Une architecture orientée services (SOA) permet d’élaborer une infrastructure

informatique d’entreprise à partir de composants associés de manière lâche
appelés « services ». Les applications composites constituent un élément clé d’un
environnement SOA. On crée ces applications en appelant et en orchestrant
plusieurs services, événements et modèles de telle sorte qu’ils constituent ensemble
un service métier de plus haut niveau. Cette fonctionnalité accroît la souplesse
opérationnelle en permettant aux directions informatiques de réutiliser des
composants qui ont déjà été testés en production et présentent des caractéristiques
connues en matière de capacité à monter en charge et de qualité du service. Cette
réutilisation accélère la mise sur le marché et réduit les coûts de développement.

Un bus de services d’entreprise (ESB) est une solution d’intégration répartie orientée
messages fondée sur des standards ouverts. Le rôle d’un ESB est de faciliter
des communications fiables entre des ressources informatiques telles que des
applications, des plates-formes et des services répartis dans plusieurs systèmes à
travers l’entreprise. Pendant que les directions informatiques se tournent de plus
en plus vers une approche SOA pour diminuer leurs coûts de développement et
augmenter l’agilité de l’entreprise, l’ESB s’inscrit comme élément fondateur d’une
architecture orientée service. L’ESB est le socle fondateur de la SOA et peut être
complété par des capacités d’orchestration et des annuaires de service. Ce livre
blanc présente la couverture fonctionnelle exigée pour un ESB mis en oeuvre dans
le cadre d’une SOA.

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
Tendance : l’adoption
des services web
standardise le
messaging SOA
L’un des défis essentiels des
développeurs a été d’intégrer
plusieurs systèmes utilisant
des langages et des formats
différents. Toutefois, l’avènement
des services web a amené des
architectures orientées services
(SOA) dotées d’un format de
messagerie normalisé — SOAP
— permettant à des systèmes
différents d’interagir. Les services
web utilisent également le langage
WSDL (Web Services Description
Language) pour décrire l’API, qui
permet à des applications écrites
sur des plates-formes différentes,
telles que C++, Java ou .NET, de
communiquer avec des interfaces
communes.
Figure 1 : Réduction de la
complexité de la connexion avec
l’ESB
Comment implémenter des services
web et des ESB
SOAP, WSDL (Web Services Description Language) et HTTP ont résolu un problème
épineux qui a contrarié les tentatives antérieures de création de standards destinés
aux systèmes répartis tels que l’architecture CORBA (Common Object Request
Broker Architecture) ou l’environnement DCE (Distributed Computing Environment) :
il s’agissait en l’occurrence d’obtenir une large acceptation des deux grandes
écoles de développement (.NET et J2EE), mais aussi de plusieurs fournisseurs
d’applications. Ce n’est pas un mince exploit, mais l’on a obtenu cette acceptation en
simplifiant à l’extrême les normes pour les réduire à un ensemble de base d’énoncés
technologiques ayant fait l’objet d’un accord. Ce principe de conception constitue à
la fois la plus grande vertu des standards de services web et leur principale limite.
En résumé, aucune implémentation ne peut fonctionner séparément sur SOAP, WSDL
et HTTP. Tandis que les services web et la SOA se font rapidement accepter dans la
communauté informatique, ils se heurtent aux mêmes difficultés que les générations
antérieures de systèmes répartis, mais à une échelle plus grande compte tenu de
leurs principes de décomposition intrinsèques. La plus évidente de ces difficultés
concerne la gestion de la mise à l’échelle des connexions point à point, également
appelée problème de connexion M*N.
La Figure 1 ci-dessous illustre l’explosion des connexions introduite par les approches
fondées sur l’intégration point à point. Pour chaque application ajoutée, le nombre
de connexions progresse exponentiellement lorsque chaque application se connecte
Avant Après
Service Bus
Connexions point à point directes (M*N) Connexion via le Bus (N)
R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
à chaque autre application. TIBCO a inventé le paradigme de l’Information Bus™,
illustré sur la droite de la figure. Dans ce modèle, chaque application se connecte
une seule fois à un backbone commun : le bus. Cela permet de réduire le nombre de
connexions et de fournir une administration centralisée des connexions, des systèmes
et architectures intégrés.

Pour gérer la complexité de la connexion et de la communication d’un client de

services avec un fournisseur de services, la SOA a besoin d’un backbone capable
de dépasser la messagerie répartie traditionnelle pour fournir une transformation,
un routage et une connectivité couplée de manière lâche complexes dans un
environnement informatique hétérogène, quelles que soient les plates-formes
utilisées. Ce backbone fiable fournit un bus de services fidèle en tout point à l’ESB.

Couverture fonctionnelle d’un ESB

Examinons les capacités du bus de services. Chacune des fonctions suivantes
constitue un élément essentiel d’une intégration réussie dans une SOA. Ensemble,
elles résolvent les difficultés auxquelles sont confrontés les clients et fournisseurs de
services dans un environnement SOA.

Messagerie répartie. Le cœur de l’ESB est constitué d’un middleware orienté

messages tel que le logiciel TIBCO Enterprise Message Service™. Ce dernier fournit
un mécanisme de transport réparti fiable en utilisant une fonction de stockage et de
transfert qui assure la remise des messages même en cas de défaillance du réseau.

Transparence de l’emplacement. Avec la médiation des services, un client de

services appelant un fournisseur de services se contente de connaître l’existence
du service et n’a pas besoin de savoir où celui-ci s’exécute. L’ESB localise le service
lorsqu’il est appelé, en offrant un niveau de virtualisation et de transparence de
l’emplacement du service, si bien que lorsqu’une machine tombe en panne ou qu’un
fournisseur de services doit être déplacé, les clients individuels du service n’ont pas
besoin d’être notifiés du changement. Cela permet de réduire considérablement les
coûts de gestion informatiques et de minimiser les risques.

Transparence du transport. Dans les approches d’intégration point à point

traditionnelles, les composants et les objets sont tous associés très étroitement.
Dans la SOA, les services sont situés d’un bout à l’autre de l’environnement
informatique et sont associés moins étroitement, en raison de la transparence de
l’emplacement. Tout en s’appuyant sur la transparence de l’emplacement pour
connecter des clients et des fournisseurs de services, l’ESB assure également une

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
liaison des protocoles de transport physique permettant la communication entre
services utilisant des transports différents.

Prise en charge multiprotocole. Etant donné que le modèle de transport HTTP

s’accompagne de problèmes de fiabilité intrinsèques et ne fonctionne bien que
pour les modèles d’échange de messages synchrones (MEP), il ne répond pas aux
exigences de chaque application ou service. JMS (Java Message Service) comporte
des caractéristiques asynchrones et dispose d’une meilleure fiabilité du transport
par rapport à HTTP. Pour prendre en charge le comportement d’applications
disparates, certains systèmes utilisent SOAP sur JMS en vue d’obtenir les effets
qu’ils recherchent. D’autres types de modèles de transport sont également utilisés,
notamment des systèmes de transport propriétaire provenant de fournisseurs d’ERP.
En conséquence, les ESB doivent être capables de prendre en charge de nombreux
types de systèmes de transport pour intégrer efficacement des environnements
hétérogènes et gérer des communications complexes au niveau du transport.

Qualité du service. Pour les applications d’entreprise, la qualité du service relève

essentiellement de la fiabilité du service. La remise des messages et l’appel fiable des
services sont des fonctions critiques d’un système, quel qu’il soit. Cependant, à eux
seuls, les services web n’assurent pas une remise garantie. En revanche, un ESB peut
offrir une haute fiabilité du service en assurant une remise des messages de bout en
bout dépassant la fiabilité que des transports tels que JMS peuvent offrir. En outre,
la haute qualité du service doit s’obtenir dans le respect des normes, en conformité
avec la spécification « WS-ReliableMessaging », par exemple.

Modèles d’échange de messages (MEP). Aujourd’hui, la plupart des ESB

fonctionnent sur un paradigme demande/réponse en utilisant SOAP sur HTTP : le
client du service envoie un message de demande à l’utilisateur et attend la réponse.
Cette approche est également appelée MEP synchrone.

Toutefois, dans le MEP publication/abonnement, le client du service peut envoyer

un message et s’abonner à la réponse, au lieu de l’attendre. Le MEP publication/
abonnement peut répondre plus efficacement à des événements survenus au sein
d’une entreprise, en particulier lorsque le cycle de vie d’une action de service se
déroule sur de longues périodes. Un ESB doit être capable de prendre en charge les
deux paradigmes.

Routage basé sur le contenu. Un ESB comporte deux types de routage. Le premier,
le routage de services, a lieu lorsque l’ESB reçoit une invocation de service puis
lorsqu’il la route vers le fournisseur de services adéquat, sans obliger le client à

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
connaître l’emplacement du fournisseur de services. C’est ainsi que la transparence
de l’emplacement évoquée précédemment est réalisée.

L’autre type, le routage basé sur le contenu, introduit un ensemble de règles ou une
logique métier qui s’applique au contenu du message au stade du routage et permet
à l’ESB de router des messages vers des fournisseurs de services particuliers — par
exemple, en classant par ordre de priorité les commandes de certains clients ou en
signalant les grandes commandes pour un traitement spécial. Ce service est précieux
pour les entreprises, car il contribue à abaisser les coûts de gestion des informations,
à garantir le respect des contrats de niveau de service et à permettre aux entreprises
de se consacrer entièrement à la satisfaction du client.

Transformation. La tâche d’un ESB est de router des messages d’un premier service
vers un second, mais il peut se présenter des cas où les formats des données
diffèrent. En conséquence, l’ESB doit être capable de transformer des données d’un
format à un autre.

Critères d’évaluation supplémentaires

En plus d’évaluer les fonctions précédentes en déterminant Ie meilleur outil
d’intégration pour une SOA, il convient d’attacher une attention particulière aux
critères suivants :

Standards ouverts. Une SOA repose sur les standards ouverts, tels que SOAP, WSDL
et JBI (Java Business Integration). En conséquence, ces standards doivent être pris
en charge à la fois par les composants de l’ESB (conteneur runtime, infrastructure
de messagerie, services d’intégration et notations de modélisation) et par les
mécanismes pour permettre à des ressources intégrées de participer (attacher,
demander et répondre) sur le bus.

Capacité à monter en charge et haute disponibilité. L’ESB doit être capable de

traiter un gros volume de messages pour répondre aux besoins de l’entreprise.
En outre, la haute disponibilité est essentielle pour veiller à ce que les opérations
métier restent ininterrompues. Si un élément donné de l’ESB subit une défaillance, il
ne doit pas nécessairement empêcher les services de communiquer.

Ces critères permettent aux directions informatiques de veiller à ce que l’ESB soit
capable de traiter la charge de transactions nécessaire de manière rapide et fiable, et
en ménageant de la place pour une croissance future : il s’agit d’un élément essentiel
de la souplesse opérationnelle.

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
L’ESB TIBCO
pour SOA
Les puissants prolongements d’un concept simple
Avec le logiciel TIBCO BusinessWorks™ introduit en 2001, TIBCO propose un
produit ESB éprouvé offrant des fonctionnalités complètes pour la conception
d’une SOA. TIBCO, qui s’est spécialisé dans l’intégration depuis plus de 20 ans, a
inauguré l’architecture orientée événement (EDA) avec l’introduction de l’architecture
Information Bus orientée service dans les années 1980. En fait, la philosophie qui
anime TIBCO est que les entreprises ont besoin d’une architecture unique prenant
en charge les services et les événements, de façon à ce que les départements
informatiques puissent exposer des informations et des applications comme des
services réutilisables sur toute l’entreprise et pour permettre le flux temps réel
d’informations orientées événement.

Avec sa vaste expérience, TIBCO comprend qu’une SOA ne se limite pas à des
services web. La plupart des ESB considèrent que tout constitue un service web, mais
des normes de services web pures ne suffisent pas à garantir l’intégration de toutes
les applications et les interfaces.

TIBCO BusinessWorks est une plate-forme extensible d’activation de la SOA

permettant d’intégrer des applications d’entreprise, de développer et déployer des
services web. Son architecture à base de bus peut être étendue pour la prise en
charge d’un vaste éventail de capacités d’intégration, offrant ainsi un outil efficace
aux organisations qui rencontrent des problèmes complexes d’intégration. En outre,
son approche consistant à « configurer plutôt que coder » permet de réduire le coût
total de possession.

TIBCO BusinessWorks dépasse le cadre des fonctionnalités ESB en offrant un

backbone d’intégration qui crée, orchestre et déploie efficacement des services
et des ressources dans une SOA. Les caractéristiques et fonctionnalités suivantes
de BusinessWorks permettent aux départements informatiques de concrétiser
pleinement les avantages d’une SOA.

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
L’appel asynchrone améliore la
souplesse de la SOA
TIBCO BusinessWorks constitue une plate-forme d’intégration à hautes performances
destinée à une grande variété d’applications et de services. En plus de prendre
en charge des services web, notamment SOAP sur HTTP, BusinessWorks propose
également SOAP sur JMS. Celui-ci permet le MEP asynchrone et accroît la fiabilité
des messages, ce qui constitue un aspect important de la qualité du service. Pour les
entreprises dont les services n’ont pas besoin d’incorporer des services web dans le
cadre de la SOA, la prise en charge du transport JMS offre toujours des avantages,
parce qu’elle est intrinsèquement plus fiable et qu’elle offre une meilleure qualité du
service qu’HTTP.

La prise en charge multiprotocole

rationalise les communications
Tous les ESB prennent certes en charge des services web, mais tous n’offrent pas
la même capacité de prise en charge de transport multiprotocole que TIBCO
BusinessWorks. Le logiciel de TIBCO est spécifiquement conçu pour gérer plusieurs
protocoles, y compris SMTP et FTP, offrant une souplesse maximale au sein d’une
SOA, améliorant ainsi l’interopérabilité entre des systèmes hétérogènes.

La médiation des services virtualise

les systèmes
En tant que plate-forme d’intégration, TIBCO BusinessWorks offre différentes façons
de rapprocher des systèmes. L’utilisation d’adaptateurs représente un élément
clé de cette interopérabilité. Etant donné que BusinessWorks constitue une plate-
forme indépendante et qu’il n’est pas lié à un fournisseur de matériel ou de serveur
d’applications particulier, il n’est assujetti à aucune technologie. BusinessWorks
comporte des adaptateurs destinés à la plupart des briques logicielles les plus
répandues, y compris des applications mainframe,Oracle et SAP.

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
 Le routage et la transformation
complexes optimisent les processus
métier
En plus de connecter des applications et des systèmes au sein d’un environnement
hétérogène, BusinessWorks fournit un très puissant moteur de transformation. La
plupart des ESB offrent une transformation simple, mais BusinessWorks prend en
charge une transformation complexe. Grâce à une interface facile à utiliser, les
développeurs peuvent concevoir des transformations très complexes sans devoir
consacrer des heures à un codage fastidieux (voir Figure 2). Du fait qu’une logique
et des règles métier sont appliquées à des messages, les fonctions et services métier
peuvent être gérés et composés plus efficacement : cela permet de réduire le risque
de conception et d’accroître la productivité.

Capacité à monter en charge et haute

disponibilité
TIBCO BusinessWorks offre un environnement fiable capable de monter en charge.
Etant donné qu’il n’a pas à être déployé sur un serveur d’applications, il ne dépend ni
de sa capacité à monter en charge, ni de sa fiabilité. En outre, plusieurs instances du
logiciel peuvent s’exécuter sur de nombreux serveurs différents communiquant entre

Figure 2 : L’approche sans

codage de TIBCO BusinessWorks Environnement Attribuer tâches
s’appuie sur une interface riche. de test intégré orientées humain
Dans la moitié supérieure de l’écran,
l’orchestration est simplifiée par des
opérations glisser-déplacer. La moitié
inférieure présente le mappage de
transformations complexes

Adaptateur,
Modélisation
processus,
du processus
configurations
graphique
de déploiement

Accès aux
Transformation
ressources par
XSLT standard
glisser-déposer

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 
eux. On obtient ainsi une disponibilité dynamique : si une première machine ralentit
sous une lourde charge, une seconde peut prendre le relais. TIBCO BusinessWorks
est également indépendant des systèmes d’exploitation. Le déploiement de
plusieurs instances apporte une capacité à monter en charge et assure une haute
disponibilité pour les transactions critiques.

Orchestration des processus

L’orchestration fait très largement partie d’une exigence métier globale, mais les ESB
les plus courants ne comportent en général pas de services d’orchestration.
BusinessWorks fait franchir un pas supplémentaire au concept d’ESB, et inclut des
fonctions pouvant orchestrer des processus métier différents au sein de l’entreprise et
composer ces services en applications.

TIBCO rationalise une approche

orientée service
Aujourd’hui, on dénombre pratiquement autant de définitions fonctionnelles des ESB
sur le marché que de fournisseurs. Toutefois, en décrivant leurs produits, plusieurs de
ces fournisseurs confondent simplicité et manque de fonctionnalités : des fonctions
aussi basiques que les adaptateurs permettant de connecter des applications
traditionnelles et prêtes à l’emploi au bus font défaut sur certains produits, alors que
d’autres souffrent de l’absence d’une infrastructure de messaging éprouvée. TIBCO
BusinessWorks fournit un ESB facile à utiliser, ainsi qu’une approche sans codage
du développement, du déploiement et de l’exécution de projets d’intégration et de
l’élaboration de SOA. En simplifiant certaines des questions d’intégration complexes
qui sont essentielles à la bonne communication entre des systèmes connectés, telles
que l’orchestration des processus et la transformation, BusinessWorks fait office de
backbone de messagerie robuste et de puissant ESB.

R ô l e d ’ u n E S B d a n s u n e n v i r o n n e m e n t S OA 10
 Pour en savoir plus
Pour tout complément d’information sur les architectures orientées service et événe-
ment (mises en œuvre, normes, gouvernance organisationnelle...), TIBCO vous invite à
accéder au Centre de ressources SOA à la page Web www.tibco.com/software/soa/.
Pour plus de détails sur les produits et services professionnels TIBCO, consultez le site
Web www.tibco.com.

Global Headquarters Tél. : +1 650-846-1000

3303 Hillview Avenue Numéro vert : +1 800-420-8450
Palo Alto, CA 94304 Fax : +1 650-846-1005 www.tibco.com

©2005, TIBCO Software Inc. Tous droits réservés. TIBCO, TIBCO Software, TIBCO BusinessWorks, TIBCO Enterprise Message Service et Information Bus sont des marques ou des marques déposées de
TIBCO Software Inc. aux Etats-Unis et dans d’autres pays. Tous les autres noms de produits et de sociétés et toutes les autres marques figurant dans ce document sont la propriété de leurs détenteurs
respectifs et ne sont mentionnés qu’à des fins d’identification. 11/05