Historiquement, les outils d’intégrations (EAI) ont été les premiers permettant de créer un « bus » d’entreprise, ou – du moins – de créer un passage obligé d’interconnexion entre différents systèmes.

Se libérer des chaînes du tout propriétaire

Les avantages de cette architecture sont assez évidents : découplage des applications entre elles, création de formats pivots dans l’entreprise… En outre, changer une application impacte uniquement la modification des connecteurs EAI.

Une question se pose alors : quelles sont les principales différences entre les ESB (Enterprise Service Bus) et les EAI ?

• Les EAI ont en interne une approche qui oblige le passage par un point centralisé. L’intégration point à point se retrouve entièrement dans l’EAI lui-même. Au contraire, les ESB ont une architecture dite distribuée : le bus est implémenté dans différents systèmes et sur différentes machines.
• Les EAI n’utilisent pas ou peu de standards ouverts. Chaque EAI fait une implémentation propriétaire de la gestion des messages. Ce qui limite les possibilités d’évolutions et pénalise la flexibilité dans des systèmes hétérogènes. Au contraire, les ESB sont conçus à partir de standards tels que la gestion des messages en java (JMS), XML, JCA (Architecture de composant standard J2EE), etc.

Cette approche de standards ouverts (open-standard) est une réponse de l’industrie du logiciel à une double contrainte :

• celle des clients n’appréciant pas la sensation d’enfermement dans une solution propriétaire, et qui refusait de l’adopter.
• celle du monde du logiciel libre qui a poussé vers ce type d’approche pour des raisons philosophiques, liées à au choix des standards ouverts favorisant l’interopérabilité.

L’open source fait jaillir l’ESB

Pour permettre d’optimiser et de mettre en commun les meilleures pratiques (Design Pattern), des initiatives ont été prises autour de modèles : les EIP ou Enterprise Integation Pattern (http://www.eaipatterns.com). Le projet Apache Camel est l’un des premiers projets open source à avoir intégré des composants standards (http://camel.apache.org).
En réaction à l’évolution du marché et à l’émergence d’offres basées sur des solutions open source, tous les acteurs historiques de l’intégration disposent désormais de leurs offres « ESB ».
L’étude de trois solutions open source destinées aux entreprises (avec des offres de service et de support) permet de comprendre les fonctions-clés d’un ESB. Cet article va donc détailler :

• la solution OpenESB (JCAPS 6) de Sun/Oracle,
• la solution Service Mix (Fuse ESB) de Progress Software,
• la solution JBoss ESB de JBoss/Redhat.

Au coeur d’un ESB 

Découplage des applications

Les applications du système d’informations ne doivent pas avoir connaissance les unes des autres. De ce fait, lorsqu’une application appelle un service métier du type « passer une commande », cela passe par l’ESB qui dirige l’appel vers la bonne application.

Conversion de protocole

Toutes les applications ne disposent pas d’une technologie qui leur permet aisément d’utiliser tous les types de protocole de communication. Par ailleurs, le programmeur peut souhaiter utiliser le service métier tel qu’il existe. Justement, l’ESB fournit une liste riche en protocoles supportés : webservice, FTP, fichier, Soap, JMS, EDI, HL7, Edifact, Swift, etc.