Quelle est la place des files d’attente de données ?

de données provenant de Java en utilisant le support fourni dans l’IBM Toolbox for Java, et accéder aux files d’attente de données à partir d’une application .NET comme c’est indiqué dans l’article « Utiliser .Net pour développer des applications de files d’attente de données iSeries » iSeries News, Décembre 2005 ou www.itpro.fr ). Si des applications existantes utilisent déjà des files d’attente de données, on peut profiter du support de file d’attente de données Java et .NET pour utiliser ces applications, tout en incorporant de nouvelles interfaces utilisateur, par exemple.

Bien que les files d’attente de données se prêtent bien mieux à la messagerie asynchrone que d’autres objets iSeries, il leur manque quand même plusieurs fonctions qui les distinguent des solutions de messagerie asynchrone. Par exemple, les files d’attente de données n’offrent aucun moyen intégré de récupération en cas de non-livraison de messages. C’est rarement un souci pour des applications iSeries fonctionnant sur un serveur unique ; en revanche, les applications distribuées craignent des défaillances de réseau susceptibles d’empêcher un message d’atteindre l’application réceptrice ou risquant de détériorer le message en transit.

Les files d’attente de données requièrent aussi l’accès direct par les deux applications (celle qui place les entrées dans la file d’attente et celle qui en reçoit les entrées). Avec les autres solutions de messagerie asynchrone, les deux applications n’ont pas forcément l’accès direct au même serveur, et un message peut naviguer sur plusieurs tronçons entre les serveurs, avant d’atteindre sa destination finale.

Enfin, les files d’attente sont peu efficaces face aux fluctuations des demandes de stockage et il est possible, particulièrement si l’application réceptrice est indisponible pendant une longue période, de remplir une file d’attente de données. D’un autre côté, les vraies solutions de messagerie asynchrone sont capables de traiter un nombre de messages virtuellement infini, sans jamais remplir la file d’attente ni dégrader la performance.

Les files d’attente de données sont une excellente technique de développement pour des communications inter-applications sur l’iSeries et pour de simples applications de collecte de données sur plates-formes hétérogènes, du genre journalisation des erreurs. Mais si vos applications se diversifient et, particulièrement, si certaines composantes sont déployées via Internet, la livraison garantie et les autres mécanismes de reprise sur erreur deviennent plus importants. Dans ce contexte, vous explorerez probablement des solutions de messagerie asynchrone plus robustes que le simple usage des files d’attente de données. En outre, quand vous utilisez des files d’attente, vous créez essentiellement une implémentation de messagerie asynchrone propre à chaque plate-forme, non standard. Et donc, si vous envisagez de déployer les applications sur de multiples plates-formes, il vaudra mieux concevoir de nouvelles applications en utilisant les technologies de platesformes hétérogènes, plutôt que des files d’attente de données.

Il existe deux approches générales pour la messagerie asynchrone sur plates-formes croisées : (1) les solutions à base de standards que l’on trouve dans Java et (2) les solutions propriétaires, comme la famille de produits WebSphere MQ d’IBM (précédemment MQ Series) et Microsoft Message Queue (MSMQ), désignées génériquement sous l’appellation MOM (Message Oriented Middleware). Les solutions propriétaires présentent un gros avantage : beaucoup des outils nécessaires pour utiliser la messagerie asynchrone existent déjà. Par exemple, IBM fournit des API permettant de mettre en oeuvre une solution WebSphere MQ à partir d’une application RPG.

La messagerie asynchrone propriétaire est très présente dans des sites mainframe qui gèrent des platesformes multiples et dans certains marchés verticaux (comme l’industrie du voyage). Cela dit, les solutions propriétaires cèdent rapidement le pas à des solutions basées sur des standards ouverts. A l’heure actuelle, le seul standard ouvert viable spécifiquement applicable à la messagerie asynchrone est JMS (Java Messaging Service). Mais, au fil du temps, il est probable que d’autres standards de communication sur plates-formes hétérogènes, comme des services Web, évolueront pour prendre en charge la messagerie asynchrone.