EAI et Décisionel

Les produits d'EAI ne sont généralement pas adaptés à l’alimentation des bases de données décisionnelles. Bien que les solutions d'EAI partagent des caractéristiques communes avec les outils d'ETL (Extract, Transform and Load), elles divergent des ETL sur certains points techniques, comme le montre le tableau suivant :

Outils d’ETL Outils d’EAI
Excellente « pompe » à données Très bon routeur de messages
En général en mode batch En général au fil de l’eau
Sources BD et fichiers le plus souvent Applications sources et cibles hétérogènes
Traite de forts volumes de données Traite de faibles volumes de données de manière fréquente
Transformations parfois complexes Transformations simples en général
avant l’alimentation

Tableau 1 : comparaison entre ETL et EAI.

Au regard du tableau précédent, on peut dire de manière caricaturale que les produits d'EAI sont orientés vers un transfert au fil de l'eau de messages de faible taille alors que les produits d'ETL fonctionnent en revanche par transferts différés d’importants volumes de données

EAI et urbanisation du SI

L’urbanisation est une démarche globale, transverse à toute le SI, qui vise une cible : celle d'un système réorganisé autour de ses fonctions et de ses référentiels partagés.
Toute transition vers une architecture fonctionnelle idéale s'opère par l'établissement d'un plan d'urbanisation. Celui-ci prévoit les différentes étapes du chantier et mène à une structuration du SI en blocs fonctionnels (zones, quartiers et îlots) faiblement couplés, qui échangent des informations en utilisant les voies de communication. La question d'une infrastructure homogène de support et de pilotage des échanges finit donc par se poser : une solution, en l’état de l’art, est d’implanter une infrastructure d’EAI pour fournir le middleware de communication dont a besoin l’urbanisation.
Pour reprendre la terminologie de l’urbanisation du SI, les applications contenues dans un quartier fonctionnel communiquent avec des applications d’un autre quartier en passant par des voies de communication fournies par l’infrastructure EAI.
L’EAI est donc un moyen permettant de passer d’un SI non urbanisé basé sur un modèle de communication point à point à un SI urbanisé basé sur un modèle en étoile.

EAI : Les bases

La perpétuelle nécessité de couvrir de nouveaux besoins dans des délais souvent brefs incite à travailler au coup par coup. Les communications entre applications sont donc conçues pour répondre au strict nécessaire dans le contexte d’un projet donné. Au fil du temps, les liens ainsi tissés entre les applications contribuent à la constitution d’un « plat de spaghettis », comme l’illustre le schéma ci-dessous.

Figure 1 : intégration en mode point à point.

Ce modèle point à point provoque une explosion combinatoire du nombre d’interfaces à gérer : pour n applications, il peut être nécessaire de gérer n*(n-1)/2 interfaces. Les conséquences de chaque évolution concernent un nombre croissant d'applications, de part les effets de bord qu’une modification peut entraîner sur les liens qui se sont tissés de manière plus ou moins formelle au fil du temps.

L'objet de l’EAI est de faire en sorte que les applications existantes et futures puissent communiquer entre elles et partager des informations de la manière la plus efficace et la plus simple possible.
Pour y parvenir, l'EAI, comme illustré ci-dessous, repose généralement sur l'utilisation d'un bus de communication en lieu et place de communications directes d'application à application.

Figure 2 : intégration avec un EAI.

La plupart des applications peuvent assez aisément se brancher sur ce bus de communication purement logiciel par l'intermédiaire d'interfaces génériques. Le modèle en n*(n-1)/2 du point à point est avec un EAI remplacé par un modèle en n.Une fois branchées sur l’EAI, il convient de faire travailler conjointement ces applications. Cela revient à mettre en relation des briques logicielles qui divergent sur différents points : modèle de données, moyens de communication supportés, etc … L’intégration d'applications constitue alors une tentative de mise en place d'une « intelligence supérieure » qui a pour objet de masquer ces différences. De son succès dépend la capacité à partager et manipuler les données de manière consistante, à bâtir des processus automatisés mettant en jeu plusieurs applications (et/ou plusieurs utilisateurs) et à construire de nouvelles applications en agrégeant des services existants. L’intégration d'applications est donc bien plus qu'un simple problème de « tuyauterie

JMX : Un standard J2EE à découvrir

Java Management eXtensions, notée JMX, est une technologie Java dont le but est le management et l’administration de ressources à travers un environnement distribué.

JMX est un standard dont les spécifications sont conduites par Sun Microsystems au travers de la JCP (Java Community Process). Cette spécification a été réalisée dans le cadre du JSR 3 (Java Specification requests). Toutes les spécifications et les informations sur ce travail sont disponible à la page suivante : http://jcp.org/en/jsr/detail?id=3.

JMX permet de répond aux problèmes de la gestion d’application JAVA distribuée:

• La gestion d’application Java. JMX rend possible la gestion d’application Java sans gros effort d’intégration au niveau du serveur. En effet, son noyau fonctionne comme un agent managé et se déploie sur la plupart des plates-formes compatibles avec la technologie Java. Concrètement, une application Java rend disponible ses fonctionnalités au travers d’un ou plusieurs beans managés dit « MBeans ». Ce MBean aura ensuite vocation à être embarqué au sein d’un objet serveur managé s’exécutant sur un serveur spécifique.
• L’intégration au sein d’environnements managés. Les agents managés, qui interfacent la gestion de ces MBeans, sont accessible à travers des protocoles HTTP, SNMP ou WBEM.
• Une architecture évolutive. Un agent managé intègre un ou plusieurs services qu’il met à disposition à travers l’appel de ces méthodes. Le service est considéré comme un module strictement indépendant à l’intérieur de l’agent. Ainsi les services n’interagissent pas entre eux. Cette architecture offre la possibilité d’écrire plusieurs versions de ce service et de les mettre à disposition sans qu’ils interfèrent entre eux. Rien ne vous empêche de réaliser un service spécifique à destination d’un réseau privé et ensuite de le déployer pour un réseau public tant en s’assurant que leurs exécutions n’interfèrent pas entre eux. La force de JMX est de pourvoir dynamiquement charger un service, de décharger ou de le mettre à jour.
• L’influence des technologies Java. JMX est citée par les spécifications J2EE. JMX est capable de cohabiter avec d’autres technologies comme JNDI, JDBC, JTS et d’en tirer partie.
  Une technologie d’avant garde. JMX est capable de tirer partie de nouvelles technologies émergentes. Pour la recherche et la découverte de service et de protocoles, JMX peut utiliser Jini, Upnp (Universal Plug’n’Play) et SLP (Service Locator Protocol).
• Se doter d’un outil de management d’application gratuit. Les spécifications JMX ont été développées via le Java Community Process. La couche Instrumentation est gratuite. Vous pouvez très bien produire vos agents bien qu’il existe déjà des outils JMX disponible gratuitement ou payant. L’outil JMX gratuit le plus populaire est MC4J. L’outil payant le plus populaire est Sun`s Java Dynamic Management Kit (Java DMK).