L’EAI (Entreprise Application Integration) : un sigle que l’on entend un peu partout… En réalité, celui-ci cache plus une problématique d’entreprise qu’une technologie. Premier point, l’enjeu de l’EAI est de permettre à l’e-business de tenir ses promesses en connectant le site web aux progiciels de gestion. Il est clair qu’une interface web de commande en ligne perd de son intérêt s’il est impossible de l’interfacer au logiciel de gestion de stocks (sur le mainframe) qu’il est hors de question de remplacer : le coût est trop élevé et l’opération trop risquée. Deuxième point, l’EAI a pour but d’intégrer l’existant, non de le remplacer. Les entreprises peuvent donc conserver leurs bons vieux mainframes ou les logiciels maison. Les applications réseau qui ont proliféré dans les entreprises (groupware, messagerie, etc. ) et la nouvelle génération d’applications web ou à base de composants sont, bien entendu, prises en compte.
Éviter l’informatique façon “plat de spaghettis”
L’intégration d’applications n’est pas un problème récent. Jusqu’à présent, les entreprises le résolvaient au coup par coup avec des développements spécifiques. Les applications échangeaient leurs données par des liaisons point à point : le programme de gestion de stocks communiquait avec la gestion de facturation, le formulaire de commande en ligne sur Internet et la logistique ; la facturation dialoguait avec la base de données clients, elle-même utilisée par le site web et le centre d’appels, etc. Cette approche est coûteuse et inefficace : selon le Standish Group, seulement 16 % des projets aboutissent. Faute d’une vision globale, on crée donc un système d’information ” spaghetti ” de plus en plus difficile à faire évoluer et à contrôler.Les solutions d’EAI visent à apporter une réponse complète à cette problématique. Elles intègrent les applications de l’entreprise par des plates-formes hétérogènes, sans exiger d’expertise dans une technologie de transport (middleware) particulière. L’EAI permet de piloter les applications grâce à une interface unifiée et de surveiller les flux de données. Remplacer ou modifier une application perturbe très peu ses voisines. Enfin, les modules conçus par différents vendeurs devraient, à terme, pouvoir cohabiter dans une même infrastructure standardisée EAI. Aujourd’hui, on reste encore assez loin de cet objectif idéal. Selon le Gartner Group, il ne faut pas s’attendre à une unification technique des différentes solutions avant 2005. Chaque projet d’EAI reste un cas d’espèce et les entreprises ne sont pas sensibilisées à l’importance d’un standard dans le domaine. Même si certains s’en approchent, aucun éditeur ne propose de solutions complètes telles que nous venons de les définir. En revanche, tous mettent en avant leurs propres produits et services, ce qui conduit à des définitions assez floues de l’EAI.La notion d’EAI est souvent présentée comme quasi synonyme de Middleware Orienté Messages (MOM), type de couche de transport le plus souvent utilisé, dont MQSeries d’IBM fut le précurseur et reste le leader. Les MOM présentent deux avantages importants. Contrairement aux ORB (Object Request Broker), il s’agit d’une couche logicielle non bloquante : l’application émettrice du message redevient immédiatement disponible, sans attendre la réponse, ce qui est très important pour l’e-business. De plus, comme les MOM gèrent des files d’attente, ils offrent un certain niveau de tolérance de panne (ou de tolérance d’applications lentes). Un message n’est pas perdu lorsqu’une application n’est pas prête à le recevoir.
Un bus de données pour le système d’information
Parmi d’autres fonctions, le middleware incorpore un mécanisme (plus ou moins sophistiqué) de routage des messages. C’est lui qui, par exemple, redirigera une commande passée par le web vers les différentes applications concernées (facturation, comptabilité, logistique, etc. ), en ne fournissant à chacune que les informations dont elle a besoin. Si la commande est passée par téléphone, ou saisie par un opérateur, seul l’émetteur change, les destinataires du message restent identiques. En fait, le MOM se comporte à la manière du bus de données d’un processeur. L’ensemble des producteurs ou des consommateurs d’un type de données peut être étendu, il suffit de connecter et de déclarer l’application correspondante au middleware, grâce à une interface logicielle.Pour bénéficier du qualificatif d’EAI, le MOM doit enfin être associé à une couche de niveau plus élevé (ou Message Broker), qui transforme les messages en un format compréhensible par les applications. Certaines d’entre elles utilisent des formats de fichiers standards, mais à moyen terme, c’est le langage de description de données XML qui devrait s’imposer dans ce domaine. Celui-ci est parfaitement adapté à cet usage, notamment par sa capacité à transporter des informations pourvues d’une sémantique précise. Il présente l’avantage supplémentaire d’être soutenu par l’industrie. Attention toutefois, même si XML est un format standard, il ne garantit pas à lui seul l’interopérabilité. XML est un métalangage, il est donc indispensable d’en préciser l’utilisation.Notons que, même lorsque les messages sont découpés en unités sémantiques, l’EAI nécessite encore des connecteurs pour assurer la communication avec les différents types d’applications de l’entreprise. Cette tâche est d’autant plus facile que l’application est récente : elle est relativement simple pour les applications à base de composants ou les grandes applications commerciales disposant d’une API, et plus complexe pour celles qui sont propriétaires ou les anciennes applications des mainframes.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
