Les EAI : un modèle fonctionnel de référence
La notion d'intégration d'applications d'entreprise (EAI) voit le jour au milieu des années 1990. Dès cet époque, les acteurs du marché l'associent à une palette fonctionnelle bien précise: la connexion, la transformation et l'orchestration des flux de données.

Les différentes briques d'un d'EAI ? Un tel outil s'articule autour d'un MOM : un middleware d'échange de messages. Apparu quelques années auparavant, à l'initiative d'IBM et de Tibco, ce type de logiciel est conçu initialement pour fournir une alternative aux logiciels de transfert de fichiers utilisés jusqu'alors pour l'intégration de systèmes. Ses principaux avantages ? Il offre de meilleures performances sur le terrain de la gestion des transactions, notamment en décomposant plus finement les volumes d'envois. Les interfaces de programmes (API), standardisées ou non (JCA, etc.), qui l'accompagnent facilitant en outre son adaptation à l'environnement technique de l'entreprise.

Avec le temps, les protocoles exploités par les MOM pour gérer le transport de messages ont évolué. Aux modèles d'objets distribués DCOM (Microsoft) et Corba (J2EE) est venu s'ajouter à partir de 2001 la solution des Web Services : le transport de messages SOAP (format XML) via Internet (sur HTTP). Un double dispositif présenté comme plus souple à déployer, car aisément adaptable aux applications.

Des évolutions à tous les étages
Reste qu'un EAI ne se réduit pas à un MOM. Il inclut également un mécanisme de transformation de données. Son objectif ? Permettre une compréhension mutuelle des applications en présence. Ce qui passe par un formatage des messages pour faire en sorte qu'ils soient correctement pris en compte par les systèmes destinataires. Ne pas confondre ce module avec un ETL (pour Extraction Transfer Loading) qui, au delà de la traduction des informations, s'étend également à l'extraction - en vue par exemple d'alimenter un entrepôt de données.

Le serveur d'intégration vient compléter l'édifice de l'EAI. Ce dernier élément se charge d'aiguiller les communications vers la bonne cible au sein du SI en fonction de règles techniques préétablies (la nature ou le contenu des messages par exemple). Mais également de superviser les opérations de traduction quand elles sont nécessaires. Ce serveur stocke l'ensemble des informations (règles de transformation et de routage) dont il a besoin au sein d'une base de données.

Du BPM au BAM
Plus récemment, les éditeurs du monde de l'EAI se sont intéressés au domaine de la gestion des processus métier (BPM), méthode depuis longtemps appliquée aux progiciels de gestion. En ligne de mire : la volonté d'ouvrir les processus techniques des EAI aux interactions humaines. Ce nouveau champ a donné naissance à des environnements additionnels de modélisation. Avec pour rôle de traduire les processus métier en flux techniques compréhensibles par le serveur d'intégration (interrogation de plusieurs bases de données, intégration des résultats dans un progiciel, conditionnement de l'opération à une validation manuelle, etc).

C'est ici qu'interviennent les produits de BAM (pour Business Activity Monitoring ou supervision des activités métier). Concrètement, cette sur-couche contribue à s'assurer de la performance des processus métier au regard de leur degré de criticité. Un projet de BAM nécessite la mise en oeuvre de deux types de briques : un outil d'intégration pour agréger l'ensemble des données techniques nécessaires (log, etc.), une solution de reporting pour compiler et présenter les résultats.

Et les ESB ?
Les ESB (Enterprise Service Bus) ne sont autres que des EAI standardisés. Pour ce faire, il font appel à la technologie XML à tous les étages du procédé d'intégration. Ils exploitent ce langage de structuration de données pour décrire à la fois le vocabulaire d'appel aux applications mais également le format des messages en lui même (ou connexion WSDL/SOAP). Là encore, les Web Services entrent en action... Avec l'évolution des travaux de standardisation, il est fort à parier que cette tendance à la normalisation gagnera à terme les niveaux les plus élevés d'un EAI, jusqu'au BPM et au BAM.

Attention : ne pas confondre un ESB avec un référentiel XML qui, de son côté, a pour but de proposer un point d'accès unique et standard à l'ensemble des données et sources de données de l'entreprise. Une sorte de portail d'accès universel dessiné pour faciliter la manipulation des informations existantes par des applications tierces (systèmes partenaires, outils de nouvelle génération, etc.).