Introduction
Le besoin grandissant d'informations consolidées et en temps réel motive de plus en plus les entreprises à trouver une
méthode pour intégrer leurs différents systèmes existants. Le processus de cette intégration est appelé intégration
d'applications d'entreprise (EAI).
Qu'est-ce qu'une intégration d'applications d'entreprise
L'intégration d'applications d'entreprise est le processus d'intégration de plusieurs applications logicielles
développées indépendamment, avec des technologies non compatibles et gérées de façon indépendante.
L'intégration d'applications d'entreprise se base principalement sur le partage et l'échange des données et processus
métier entre les différentes applications et sources de données de l'entreprise.
Types d'intégration d'applications d'entreprise
L'intégration d'applications d'entreprise peut se faire à plusieurs niveaux, en fonction de nombreux facteurs, y
compris la taille et le secteur de l'entreprise, la complexité de l'intégration et/ou du projet, ainsi que le budget.
Il existe quatre niveaux principaux d'intégration :
Niveau données
L'intégration d'applications d'entreprise au niveau données est une approche centrée sur les bases de données
consistant à extraire des données d'une base pour les mettre à jour dans une autre base de données. Les données
extraites peuvent parfois être transformées avant d'être entrées dans la base de données cible, pour appliquer des
règles métier spécifiques par exemple.
L'intégration au niveau données s'effectue généralement grâce à des outils d'alimentation qui permettent l'extraction,
la transformation et le chargement des données provenant de plusieurs sources vers un référentiel de données
d'entreprise commun (entrepôt de données) ou des référentiels de données adaptés à différents besoins métier (magasins
de données).
Les principaux avantages de cette approche sont son faible coût et son profil de risque peu élevé. Dans la mesure où ne
modifions pas le code existant des applications, les dépenses liées au développement, au test et au déploiement de
nouvelles versions des applications ne sont pas nécessaires. Les principaux désavantages de cette approche sont la
génération de nombreuses bases de données et tables, la nécessité pour le concepteur de base de données de comprendre les données déplacées
ainsi que les règles métier associées.
Niveau interface d'application
Ce niveau d'intégration d'applications d'entreprise consister à optimiser les interfaces fournies par les applications,
personnalisées ou non, pour accéder aux processus métier et aux simples informations. Ce type d'intégration est
généralement effectué en trois étapes :
-
Extraction des informations d'une application grâce à une interface d'application fournie.
-
Conversion des données à un format que l'application cible peut comprendre.
-
Transmission des informations à l'application cible.
L'approche la plus courante pour ce genre d'intégration est appelée "courtier de messages". Elle normalise et contrôle
le flux d'informations via une structure de bus ou de hub.
En raison de la popularité grandissante des services Web, les applications de package et les applications existantes
les utilisent de plus en plus pour exposer les fonctions métier. La disponibilité de ces fonctions métier en tant que
services réutilisables augmente le recours à l'utilisation d'une architecture SOA en remplacement du "courtier de messages".
Le principal avantage de cette approche est la relative facilité de l'interfaçage entre les différentes applications
car les interfaces d'applications sont fournies par application. Le coût de la technologie de courtier de messages est
un aspect négatif de cette approche. Par le passé, ces interfaces dépendaient souvent de l'application et obligeaient
les développeurs à apprendre les fonctions et fonctionnalités spécifiques de chaque interface. Avec la popularité
grandissante du langage XML et son adoption comme langage standard pour de nombreuses interfaces d'application, ce
problème est en train de disparaître.
Niveau méthode
L'intégration au niveau méthode est similaire à celle du niveau interface d'application si ce n'est que le niveau de
granularité est plus faible. Le principe est de ne pas partager les fonctions métier (comme c'est le cas au niveau
interface d'application) mais de partager directement les différentes méthodes utilisées pour composer une fonction
métier spécifique. Toutes les autres applications d'entreprise devant implémenter les mêmes méthodes peuvent utiliser
celles-ci sans qu'il soit nécessaire de les récrire.
Même si ce niveau d'intégration peut être effectué avec de nombreuses technologies (Java RMI, Corba, DCOM, etc.), la
tendance actuelle pour l'implémentation de cette approche est d'utiliser des services Web pour partager les méthodes.
La capacité à partager des méthodes et réutiliser une logique métier rend cette approche très adaptée à l'intégration
d'applications d'entreprise. Mais l'inconvénient de cette approche est qu'elle est également la plus intrusive car elle
implique la modification des applications existantes pour permettre le partage à un tel niveau.
Niveau interface utilisateur
L'intégration d'applications d'entreprise de niveau interface utilisateur est souvent appelée "rectification" et
consiste à remplacer les interfaces utilisateur texte des systèmes en vigueur et les interfaces graphiques des
ordinateurs existantes par une interface normalisée, généralement de type navigateur.
La solution des portails d'entreprise est de plus en plus utilisée pour ce type d'intégration. L'objectif est de
fédérer la présentation de plusieurs applications en une seule interface personnalisable de type navigateur.
Ce type d'intégration est moins onéreux que d'autres approches car le code des applications existantes n'est pas
modifié. Cependant, pour les mêmes raisons, cette approche est également moins flexible.
Interface d'applications d'entreprise et middleware
Dans le cadre d'une intégration d'applications d'entreprise, la technologie middleware n'est utilisée qu'en tant que
mécanisme permettant de déplacer des informations et de partager des processus métier entre des applications. Le
middleware masque la complexité du mécanisme de communication entre les systèmes source et cible. Cela permet aux
développeurs de se concentrer sur les API (Application Programming Interfaces) de chaque système pendant que le
middleware gère le transfert des informations entre les deux systèmes. La même APIT middleware peut être utilisée par
différentes applications exécutées sur différentes plateformes.
En tant que technologie sous-jacente de l'intégration d'applications d'entreprise, le middleware peut être utilisé à
tous les niveaux d'intégration (y compris au niveau interface utilisateur car les
portails d'entreprise peuvent être considérés comme une sorte de middleware). Bien sûr, l'utilisation la plus courante
de la technologie middleware est avec un courtier de messages au niveau
interface d'application.
Interface d'applications d'entreprise et XML
La norme XML (eXtensible Markup Language) est une spécification de langage de balisage basée sur du texte du consortium
World Wide Web et dont l'objectif est de définir des données structurées portables. Dans la mesure où le format XML est
simple et de plus en plus largement utilisé, il est idéal comme protocole et format de message d'intégration
d'applications d'entreprise.
Le langage XML peut être utilisé avec tous les niveaux d'intégration (à l'exception peut-être du niveau interface
utilisateur). Il peut être utilisé comme format d'échange de données courant au niveau données, comme format de message
et/ou protocole dans le courtier de messages au niveau interface d'application, ou bien comme support de services Web
dans une architecture SOA. Dans la mesure où les services Web sont construits en utilisant le
langage XML, celui-ci a également sa place dans une intégration au niveau méthode.
Lectures et références supplémentaires
-
David Linthicum, Next Generation Application Integration: From Simple Information to Web Services, Addison-Wesley,
2003.
-
Gregor Hope and Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley, 2003.
|