I.T. aware

Pour résumer rapidement, après le client lourd où l’applicatif se voyait dupliqué sur chaque poste client, on est passé au client léger où l’applicatif se situe en grande partie sur un serveur d’applications et facilite le déploiement et la maintenance.
Cependant le client léger a été critiqué par les utilisateurs pour son manque d’interaction avec les outils du bureau (en particulier l’Office suite) et sa dépendance au réseau lié au HTML et au principe d’HTTP. Est donc apparu le client riche qui redonne aux utilisateurs des interfaces plus ergonomique et moins dépendante du réseau. L’intelligence logicielle est maintenant répartie équitablement entre le client et le serveur.
Le schéma ci-dessous illustre cette évolution :

Un nouveau concept implique un nouvel acronyme : le RIA pour Rich Internet Application. Utilisé à tout va celui-ci mérite d’être plus clairement défini. Le schéma ci-dessous propose donc de décomposer le RIA en 2 sous ensembles : les RDA pour Rich Desktop Applications (pour les applications orientées bureau, exécutées sur le client et non dans un navigateur Web) et les RWA pour Rich Web Applications (pour les applications orientées Web déployées à travers le navigateur).

Pour aller plus loin, comme le montre le schéma, les deux sous ensembles peuvent être étendus vers la notion de « plate-forme » qui propose de faciliter le développement d’applications en utilisant une base commune, modulable, avec des fonctionnalités classiques (menu, splashscreen, vue, …). Les exemples cités dans le schéma ne sont pas exhaustif et il serait intéressant d’en faire une liste plus compléte.

La question qui se pose est maintenant de savoir laquelle des deux branches, desktop ou web, choisir pour développer son application. Le problème du déploiement (qui a fait le succès du client léger) se pose toujours pour les applications desktop. Encore qu’il n’en est pas un pour les applications Java depuis l’arrivée de Java Web Start. Coté Microsoft et Macromédia la question se pose différemment, WPF/e et Flex permettent de diffuser les applications via un plugin dans le navigateur mais on ne parle plus alors de RDA.
La frontière entre RDA et RWA n’est donc pas toujours évidente. Si l’on prend l’exemple de Firefox et XUL on a un navigateur qui offre des fonctionnalités desktop, comme le ferait une application Eclipse RCP qui inclue un navigateur. Inversement une application Flex n’est liée au navigateur que par le plugin, l’interaction avec celui-ci reste possible mais les composants restent eux totalement indépendants du navigateur. Ce qui nous amène alors au concept de RSP (Rich Server Platform) qui propose de combiner navigateur et desktop en une seule et même application.

D’autre part pour le concept RIA l’architecture applicative à 5 couches reste d’actualité mais elle doit évoluer pour prendre en compte les spécificités du client riche et plus particulièrement pour le RDA.

Les couches application et entreprise doivent se scinder en 2 pour séparer ce qui concerne la partie serveur de la partie cliente. Entre cette séparation viens se glisser la couche de communication. C’est dans cette couche que les services web trouvent leur place mais pas seulement eux. Parmis les framework qui implémente cette couche il faut citer WebObjects EODistribution, Cayenne, Spring remoting. On constate que ces exemples n’utilisent pas les services web, il y a donc d’autres alternatives, c’est d’ailleurs le choix de Microsoft à travers WCF qui se veut être un framework d’échange complet, i.e. pas seulement basé sur les services web mais sur toutes les formes de communications possibles (WCF représente environ 70% de .NET 3.0).
Cette approche est moins vrai pour le RWA car aujourd’hui aucun framework Javascript n’offre la possibilité de mettre en oeuvre des couches, mais cela peut évoluer…

Bref tout cela ne m’aide pas à répondre à ma question, quelle branche choisir ? Le client riche a des avantages ergonomiques et de fonctionnalités au niveau du client, mais les technologies pour le mettre en oeuvre sont nombreuses et pas toujours concurrentes. Il nous faudrait définir une échelle de valeur qui donne en fonction de besoins la technologie, ou du moins la branche la mieux adaptée.