Dossier réalisé en partenariat avec Dreamsoft

Mise au point

Notions de base

Architectures & offres

Sybase-NEON

		BEA
		webMethods
		Seebeyond

L'EAI, nous l'avons vu précédemment, s'apparente plus à un concept qu'à une solution. Et ce concept ne renvoie pas à un modèle d'architecture mais au moins à deux modèles: "Hub and spoke" et 'Network Centric".

L'architecture "Hub and spoke"
C'est le modèle centralisé de l'EAI. Ici, tout passe par un "hub" central. Aucun flux n'est possible sans l'entremise de ce hub. Quand une application envoie un message, ce dernier est expédié à destination du hub. Le référentiel (la base où sont stockées les règles de routage et de transformation) est donc lui aussi centralisé. L'avantage d'une telle architecture saute aux yeux: l'administration est grandement facilitée. "En revanche, prévient Marc Muller, PDG de Dreamsoft, la gestion de la charge s'avère complexe dans ce type d'environnement: la seule solution consiste en effet à multiplier les hubs sur les différents segments du réseau, sachant qu'il faudra veiller à synchroniser les règles stockées sur ces différents noeuds". L'administration devient alors moins aisée.

L'architecture "Network Centric"
Il s'agit cette fois de la version décentralisée de l'implémentation de l'EAI. Des référentiels de règles et des gestionnaires de messages sont distribués sur l'ensemble des noeuds (point de connexion à une application). Quand une application émet un message, ce dernier est traité par le référentiel du noeud correspondant afin que les applications abonnés à ce type de messages le reçoivent. Avec ce type d'architecture, la charge est donc naturellement répartie sur l'ensemble des noeuds.

Une différence pas uniquement technique
"L'une de ces architectures n'est pas fondamentalement meilleure que l'autre. Une étude au cas par cas s'avère nécessaire pour les départager", estime Marc Muller. D'autant que cette dichotomie technique a des conséquences tarifaires. Une plate-forme de type "Network Centric" est facturée en premier lieu en fonction du nombre de noeuds; résultat, le client doit d'embler payer pour le périmètre des applications qu'il souhaite couvrir. En revanche, avec le modèle "hub and spoke", un client a la possibilité de n'utiliser qu'un seul hub dans un premier temps pour couvrir un large éventail d'applications. Autrement dit, l'architecture "hub and spoke" donne plus de souplesse que sa concurrente pour acheter des hubs au fur et à mesure de la montée en charge. Le détail n'est pas anodin: c'est l'une des explications de la percée d'un webMethods, digne représentant de l'architecture "Hub and spoke".

Les autres points de différenciation des offres
Pour élaborer les fiches accessibles depuis ce tableau, voici quelques unes des questions que nous nous sommes posées. Une liste indicative et non exhaustive.

- Cohérence de la solution :
Toutes les briques de la plate-forme (connecteurs, serveur d'intégration, outil de BPM) sont-elles bien intégrées ? Partagent-elles par exemple un même référentiel ?
- Puissance de l'outil de BPM
L'outil de BPM est-il capable de gérer les interactions humaines ? Quelle supervision des processus permet-il ?
- Connecteurs
La plate-forme dispose-t-elle d'un bon éventail de connecteurs ? Un kit pour développer ses propres connecteurs est-il fourni ? Quels types d'échanges B to B peuvent être gérés (EDI ? Swift ? Rosettanet ? cXML.) ?
- Productivité
L'ergonomie des outils garantit-elle une bonne productivité, dans les phases de développement et de déploiement ? Facilite-t-elle la gestion des versions et le travail en groupe ?
- Compétences requises
A quelles compétences la plate-forme fait-elle appel ? (Java ? XML ? Autres ?)