C’est un fait les applications Web deviennent asynchrones. En effet l’arrivée d’AJAX à permis d’en finir avec des temps de réponse long due à la vielle pratique du response-request loop pour charger une page entière. Bien avant AJAX cette technique était déjà pratiquée en utilisant une Applet cachée qui permettait d’accèder à un MOM (Message Oriented Middleware). Le MOM ne serait il pas en train de s’imposer comme l’architecture d’échange la plus appropriée des applications web ?
Je constate actuellement en tout cas que c’est une réponse à un besoin des applications web pour gérer différents aspects
- synchronisation,
- temps de réponse,
- mode déconnecté,
- assurance de l’acheminement des données.
Actuellement le MOM est surtout utilisé pour les deux premiers aspects et moins pour les deux suivants. La plupart du temps c’est un serveur dédié à cela vers lequel les messages sont transmis. Si ce serveur tombe ou que le réseau est coupé en amont l’applicatif renvoi une erreur de transmission. C’est typiquement le cas dans Life Cycle Data Service : le mode messaging permet de synchroniser et d’améliorer les temps de réponse, mais si on coupe le réseau les messages envoyés par le client sont perdus. Par ailleurs l’application que je développe actuellement utilise Eclipse RCP pour embarquer une application Web qui communique aussi avec du messaging à la différence que j’utilise une queue locale, qui m’assure l’acheminement de mon message. La solution s’appuie sur MQSeries et MQ Everyplace d’IBM et la mise en place est complexe mais elle répond aux 4 aspects. Pour que Life Cycle Data Services puisse faire la même chose et ainsi proposer des applications mobiles adaptées il faut faire évoluer le Flash Player pour permettre au développeur d’utiliser une queue locale.
Est-ce la fin d’HTTP ? La est l’inconvénient d’une architecture asynchrone car l’intérêt d’HTTP est de passer les firewall et l’utilisation d’un autre protocole bride la diffusion d’une application web. Qu’a cela ne tienne il suffit d’exploiter le protocole HTTP avec du MQ ce qui se fait déjà.
N’oublions cependant pas que ce modèle implique que l’utilisateur ne soit pas dépendant de la réponse, or la plupart des requêtes le sont. D’où la nécessité d’une base de donnée locale permettant le mode déconnecté. Les échanges client / serveur étant alors réduit à une synchronisation de base de données à base de données. Cela ne devient il pas trop lourd en terme de déploiement et de gestion ? pas vraiment car les bases de données embarquées existent déjà (Java DB via Java Plugin, SQLite via Google Gears) . Oui mais qu’en est il du chargement de la base de données ? En effet il faut bien initialiser cette base au moins une première fois ce qui peut prendre du temps mais tout dépend du besoin attendu.
Cette architecture représentée dans le schéma ci-contre est sûrement l’idéale pour certains types d’applications Web nécessitant une autonomie. Elle est encore difficile à mettre en place car elle demande un paramètrage lourd et les outils ne sont pas intuitifs. A terme cela devrait devenir complètement masqué au développeur qui utiliserait des méthodes send/receive sans se préoccuper du reste. Les solutions sont la car le messaging est une technologie éprouvée, il nous manque juste un outil ou un framework permettant la mise en place d’une telle architecture d’une manière simple.
