L'intégration à l'heure SOA – (2) ESB et EAI, divergences et convergences

Après les solutions d'EAI / BPM de la fin des années 90, sont arrivées sur le marché de nouvelles approches de l'intégration, plus légères et plus souples, et adaptées à la mise en oeuvre d'une architecture orientée services. Le point, dans cette deuxième partie de notre dossier, sur les spécificités des technologies ESB (Enterprise Service Bus), par rapport aux techniques de l'EAI.
Par Muriel Guénon

Les technologies et les approches de l’intégration ont beaucoup évolué dans les systèmes d’information. Loin de remplacer les anciennes technologies, les nouvelles se sont ajoutées à elles, afin de couvrir des problématiques nouvelles. L’une des plus anciennes technologies, le transfert de fichiers (FTP), est toujours largement utilisée dans les entreprises pour transmettre des données entre applicatifs. Ainsi, plusieurs générations de technologies d’intégration se sont superposées dans les systèmes d’information des entreprises.




Vers la fin des années 90, les solutions d’EAI/BPM ont constitué la réponse prédominante des éditeurs à la problématique d’intégration des applications, au sein de l’entreprise ou entre l’entreprise et ses partenaires. Malgré de belles réalisations et passé l’enthousiasme excessif qu’elles ont soulevé à la fin des années 90, les solutions d’EAI ont parfois suscité de sévères critiques, parmi lesquelles :

• l’aspect pharaonique des projets d’EAI dont certains importants se sont soldés par un échec,
• les technologies propriétaires de ces offres à l’opposé du principe d’urbanisation,
• des tarifs de licence souvent excessifs : de fait, les grands comptes ont longtemps été la cible privilégiée voire exclusive des éditeurs d’EAI.

L'EBS, un médiateur entre fournisseurs et consommateurs de services

Parallèlement à l’essor des architectures SOA, une nouvelle catégorie d’outils est apparue, les Enterprise Service Bus (ESB), qui viennent constituer un socle de déploiement pour ces architectures en mettant en œuvre certains de leurs principes fondateurs : réutilisation, couplage lâche, interopérabilité.

L’ESB est un intermédiaire, un médiateur entre les fournisseurs et les consommateurs de services. Il permet en effet de découpler les échanges entre fournisseurs et consommateurs de services et d’éviter qu’ils ne communiquent entre eux en utilisant des connexions point à point. Encore faut-il pour cela respecter certains principes d’architecture : privilégier un mode d’échange asynchrone, anonyme et événementiel, et s’appuyer sur un format d’échange pivot pour ne pas faire des transformations point à point. L’ESB fournit des services de transport, de transformation des formats de données, de routage intelligent, d’équilibrage de charges et de gestion de la sécurité tout en coordonnant le flux des appels de services.

Si l’ESB fournit un socle de fonctionnalités identiques à celles apportées par les solutions d’EAI/BPM, il se distingue par les caractéristiques suivantes :

• son support natif des standards tels que XML, JMS, JCA, JMX et les nombreux standards relatifs aux Web Services (comme WS-Reliable Messaging, WS-Addressing, WS-Security, etc.). Dès le départ les EXB ont parlé XML, ont établi les interactions qu’ils supportent sur les spécifications JMS et bien entendu ont supporté les Web Services.
• son 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.
• son architecture distribuée : l’architecture de services des ESB peut être distribuée avec beaucoup plus de modularité qu’une architecture plus monolithique, ce qui permet d’apporter une réponse précise et souple aux besoins de ‘scalabilité’ rencontrés dans les problématique de montée en charge.
• en revanche, la couverture fonctionnelle des ESB est moins large et moins riche que celle des grandes plates-formes d’EAI, restant principalement focalisée sur les fonctions essentielles de l’intégration.
• sur le plan commercial les ESB présentaient des coûts de licence bien moindres que ceux des grands EAI. Cependant les coûts générés par de la mise en œuvre d’un ESB se sont avérés souvent supérieurs à ceux induits par celle d’un EAI.

Enfin, ce segment a été enrichi par la contribution de plusieurs réalisations Open Source.

Différences initiales entre les ESB et les EAI (Source Le CXP)


L’apparition des ESB, plus adaptés par leur architecture de services à l’évolution vers SOA, a fait bouger les éditeurs traditionnels d’EAI / BPM. Ils ont suivi le mouvement en changeant l’appellation de leurs offres (on a vu un temps fleurir le terme ESB chez plusieurs éditeurs d’EAI pour désigner une version "light" de leur offre !) et, plus sérieusement, en infléchissant l’évolution technique de leurs plates-formes pour prendre en compte les standards (XML, Web Services, JMS, etc.) et répondre à certaines exigences liées aux architectures SOA (virtualisation des services, sécurisation des appels, équilibrage de charge entre services, etc.).

Les ESB, de leur côté, ont étendu leur couverture fonctionnelle et proposent désormais des fonctions d’orchestration des services, voire de gestion de processus. Quant aux éditeurs de solutions d’EAI/BPM, ils ont perçu l’importance du mouvement d’évolution des Systèmes d’Information vers les architectures SOA et ont continué d’enrichir leur offre en proposant désormais des outils de gouvernance SOA.

Evolutions parallèles des ESB et des EAI (Source : Le CXP)


Aujourd’hui, si des différences subsistent, les deux catégories d'offres tendent à se rapprocher et peuvent permettre tout aussi bien la mise en œuvre d’interactions basées sur le principe du couplage lâche.

Par ailleurs, les architectures SOA ont pour vocation de permettre la composition et la recomposition agile des processus métier : les outils de BPM viennent les compléter tout en s’appuyant et en tirant parti du découpage en services du système d’information. Ces facultés de réutilisation et de recomposition permettent au système d’information de mieux absorber les changements et de réagir plus rapidement aux évolutions souhaitées côté métier.

Les plates-formes d’intégration se sont enrichies depuis plusieurs années d’une couche d’orchestration ou de gestion des processus qui permet de composer et d’automatiser le déroulement d’un processus. De leur côté, les ESB aussi ont intégré une couche d’orchestration, quoique moins développée que celle de certains EAI qui ont une longueur d’avance en la matière. Cependant, malgré son bien-fondé, cette couche d’orchestration des bus d’intégration, EAI ou ESB, a souvent généré bien des ambiguïtés : le terme de processus métier a souvent été abusivement employé pour désigner des processus d’intégration ou des itinéraires ESB, et nombre de processus hybrides, issus d’une problématique d’intégration, enchaînent dans leur déroulement des activités techniques d’intégration (routage, transformation, etc.) et des services métier (ex. : enregistrement d’une commande).

Les bus d’intégration, ESB ou EAI, doivent encore progresser pour trouver leur place exacte dans l’écosystème opérationnel des architectures SOA. Alors que de grandes offres d’intégration combinent au sein de leurs plates-formes, au-dessus des fonctions classiques d’un bus, une couche conséquente de gestion des processus, un moteur de BAM (Business Activity Monitoring) et un portail permettant de créer des applications composites, d’autres solutions ont un périmètre fonctionnel plus ciblé. Quelle que soit l’ampleur des offres, la présence d’une couche d’orchestration des services, voire de BPM est désormais systématique. En revanche, la place du bus d’intégration vis-à-vis des annuaires de services et vis-à-vis des référentiels de méta-données n’est pas encore clairement établie et reste variable d’une offre à l’autre (inclusion de ces outils dans la plate-forme d’intégration ou interface avec ces catégories d’outils…).


Dans notre prochain numéro : L'intégration à l'heure SOA - Typologie de l'offre

Le CXP a publié un Service Expert consacré à la problématique EAI, BPM, ESB au service des architectures SOA.

L'Oeil Expert, octobre 2007