Autrement dit, en fonction d'événements préalablement définis, un logiciel d'EAI récupère les données d'une application, puis les "route" vers leur destination (une autre application), non sans les avoir préablement converties dans un format adéquat. A cette fin, il met en oeuvre:

- un serveur d'intégration qui comprend un moteur de règles et un gestionnaire de messages (pour le routage et la transformation)

- des connecteurs (pour dialoguer avec les applications)

- et un MOM (middleware orienté messages) pour transporter les messages. Quasiment tous les fournisseurs d'EAI disposent de leur propre MOM même si la plupart du temps les plates-formes d'EAI sont déployées sur des MOM déjà installés dans l'entreprise.

A notre sens, une plate-forme d'EAI couvre donc ces quatre étapes. "Par comparaison, un logiciel d'ETL, comme son nom l'indique, peut extraire et appliquer des transformations à des données, mais n'est nullement conçu pour appliquer des règles de routage complexes", précise Marc Muller. Cela dit, un outil d'ETL peut répondre, dans une certaine mesure, à des besoins d'échanges de données - d'où la confusion.

La gestion des processus métiers (BPM, pour Business Process Management) prolonge assez naturellement les quatre fonctions de l'EAI. Le BPM ajoute une couche d'abstraction où l'information manipulée n'est plus une donnée ou un flux technique d'une application vers une autre mais un processus métier. A travers le logiciel de BPM, un architecte métier défini un processus (par exemple le circuit de validation des informations concernant un nouveau client) qui sera traduit en flux techniques, lesquels sont transmis au serveur d'intégration à des fins de paramétrage. Dans la réalité, ce n'est pas vraiment une surprise, tout n'est pas aussi transparent et automatique. "Passer les informations du BPM au serveur d'intégration, précise le PDG de Dreamsoft, demande des interventions humaines pour, au minimum, finaliser le paramétrage technique".

Avec l'ouverture croissante du système d'information aux partenaires et clients, les éditeurs d'EAI ont naturellement étendu le champ d'action de leurs plates-formes à l'intégration B to B. A cette fin, beaucoup de ces éditeurs ont rendu leur plate-forme capable d'interpréter les sémantiques définis par des consortiums tels que RosettaNet. Dans le domaine de l'intégration B to B, deux grandes écoles cohabitent:

- ceux qui, à l'instar de webMethods, estiment que les flux B to B exploitant les technologies Web (de http à XML) ne sont pas de la même nature que les flux internes. Et demandent donc des serveurs d'intégration distincts.

- ceux pour qui, à l'instar de Seebeyond, l'intégration B to B prend la forme d'un connecteur enrichi de fonctionnalités relatives aux problématiques B to B et qui s'adosse au serveur d'intégration également exploité pour les flux internes.

Ce débat ne doit toutefois pas trop monopolisé l'attention de l'utilisateur. Au moins dans un premier temps. Les points de différenciation critiques des offres d'EAI sont plutôt à chercher du côté des modèles d'architecture qu'elles implémentent.

Mise au point

Notions de base

Architectures & offres