Si une solution d’intégration d’applications tend à exhiber l’intelligence de ses connecteurs ou son aptitude à gérer les processus métier, sa fonction essentielle n’en demeure pas moins le transfert de données. Ce rôle est assumé par le middleware asynchrone, ou MOM (Message Oriented Middleware). Dans ses grandes lignes, un MOM associe un mode de transmission des données sous forme de messages à un mécanisme de mise en files d’attente (message queues) et un système de pilotage de ces files d’attente (queue manager). Un middleware asynchrone dispose d’interfaces de programmation C, C++ et Java, se doit de supporter plusieurs modes de communication (datagramme, request/reply, conversationnel et, surtout, publication/ abonnement).
Encore beaucoup d’interfaces maison
Mais garantir la délivrance des messages ne suffit plus. Intégrer des logiciels nécessite aussi de mettre en ?”uvre des fonctions d’extraction et de traduction des données, d’administration, d’historisation, etc. D’où une première évolution des MOM vers le modèle des courtiers de messages, où de multiples applications communiquent entre elles par l’intermédiaire d’un “courtier”, chargé du routage des messages. D’autres améliorations ont porté sur l’ouverture des interfaces d’administration des MOM. Sans compter le renforcement de leur capacité transactionnelle (avec l’intégration de mécanismes de roll-back et two phase commit) et de leur niveau de sécurité (avec la prise en compte du protocole de sécurité SSL et de l’équilibrage de charge). Mais sur le terrain, les infrastructures d’interfaçage d’applications sont encore loin de toutes faire appel aux middleware asynchrones. Beaucoup d’interfaces ont été et sont encore développées de façon spécifique, sont de type “point à point”, ou se basent sur les techniques de type “batch “. Il est, par exemple, encore habituel d’interfacer des applications grand système et PGI en faisant appel à des progiciels de transfert de fichiers, tel XFB, de Sopra.Reste que le rôle des MOM est inéluctablement appelé à se développer ?” ne serait-ce que parce que ce type de middleware est à la base de tous les ateliers EAI (Enterprise Application Integration) modernes. Il revient cependant aux éditeurs d’outils d’intégration d’application d’entreprise de proposer leur propre mécanisme de transport tout en restant ouverts à l’existant middleware. Pour ne donner qu’un exemple, l’atelier EAI de Webmethods s’appuie sur sa propre couche de transport, mais il dispose aussi de connecteurs adaptés aux MOM compatibles JMS (Java Message Service) et à MQSeries, d’IBM. Cette capacité de dialoguer avec des middleware asynchrones de tierce origine n’est pas la moindre des aptitudes des plates-formes d’intégration d’applications modernes. Il serait, en effet, illusoire de penser qu’un projet EAI, impose systématiquement de casser les infrastructures d’intégration interapplicatives préexistantes et ayant fait leurs preuves par le passé.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
