Dépassés, HTML et le client-serveur ? C'est ce que laisse supposer l'émergence de nouveaux langages XML, permettant de décrire et d'assembler dynamiquement un nouveau type d'interfaces utilisateur. « De nombreux éditeurs sont en course pour contrôler la couche de présentation des architectures orientées services. Celui qui s'imposera contrôlera le poste client de demain », confirme Didier Girard, directeur technique d'Improve.

Jusqu'à aujourd'hui, les entreprises créaient des interfaces HTML ou client-serveur pour accéder à leur logique métier ­ ajout, modification, ou suppression d'une commande, par exemple. Bien que reconnu pour sa portabilité et sa simplicité de déploiement, HTML reste peu ergonomique. A l'inverse, les applications client-serveur sont appréciées pour leur ergonomie, mais les déployer coûte cher. Et, dans tous les cas, le choix de l'une ou l'autre de ces architectures impose de développer, de déployer et de maintenir une interface utilisateur à chaque fois spécifique, et en outre statique dans le cas d'une architecture client-serveur. Une application client-serveur destinée à différents publics ­ clients et employés, par exemple ­ mais recourant aux mêmes fonctions métier nécessite donc de compiler, de déployer et de maintenir deux interfaces utilisateur.

A la suite du développement des services web et des connexions à haut débit, une nouvelle approche, basée sur des langages XML de description d'interfaces, donne naissance à une troisième architecture : le client riche internet (ou Rich Internet Application). Hybride, elle réunit le meilleur du client-serveur ­ traitement sur le poste client, richesse et rapidité de l'interface graphique, mode déconnecté, etc. ­ et du web ­ communication standard sur HTTP et Soap, déploiement en un clic, personnalisation à la volée, etc.

Encore émergente, l'architecture client riche s'appuie sur un socle d'exécution installé sur le poste client ­.Net Framework, Java Runtime Environment, lecteurs Flash et PDF, etc. Ce socle d'exécution joue le rôle d'un « supernavigateur » , qui embarque avec lui tous les éléments graphiques génériques de l'interface ­ boutons, fenêtres, menus, etc. ­, ainsi qu'une couche de communication XML/Soap sur HTTP. Construire un client riche revient donc à indiquer au socle d'exécution quels éléments graphiques assembler pour former un écran, comment les enchaîner, quels services web appeler, comment valider les saisies de l'utilisateur, etc.

En théorie, il suffit de décrire l'ensemble de ces informations dans un fichier XML ­ interprété sur le poste client ­ pour créer l'application. Une démarche en tous points similaire à la construction d'une page web. Sauf qu'un client riche est déployé au sein d'un container, avec tous les éléments graphiques, traitements, etc. qui ne sont pas présents sur le socle d'exécution.

Le World Wide Web Consortium (W3C) a tenté de canaliser la frénésie qui s'empare des éditeurs en lançant SVG Rendering Custom Content (SVG.RCC) et XML Forms (XForms). SVG.RCC spécifie comment transformer un langage XML de description d'interfaces ­ XForms, par exemple ­ au sein d'un client vectoriel basé sur Scalable Vector Graphics (SVG). Cependant, moribonde, l'honorable institution n'a pas réussi à fédérer ses membres. Si bien que des alternatives concrètes, mais propriétaires ont vu le jour : XML User Interface Language (XUL) de Mozilla, Macromedia XML (MXML) de Macromedia, XML Application Markup Language (XAML) de Microsoft, XML Data Package (XDP) d'Adobe, etc.

Le navigateur Mozilla s'appuie sur XUL, un jeu de composants graphiques prédéveloppés, et un interpréteur. L'ensemble de ces briques est installé une seule fois avec le navigateur sur le poste client. Le déploiement d'une nouvelle application XUL ne nécessite donc qu'un simple clic sur une URL. La création du fichier XUL décrivant l'application peut s'effectuer dynamiquement côté serveur à l'aide de n'importe quel langage ­ ASP, PHP, JSP, Perl, etc. « XUL est une technologie fantastique pour faire du client riche. Il suffit de tester le navigateur de CFMentor, qui interface les services web d'Amazon, pour s'en convaincre. Cette démonstration donne une idée de ce que pourrait être l'utilisation de XAML dans Internet Explorer 7 », analyse Didier Girard. «  C'est pourquoi XUL n'aura un bel avenir que s'il parvient à être intégré dans J2SE [Java 2 Platform, Standard Edition ­ NDLR] », estime Sami Jaber, consultant chez Valtech.

Même si elle ne verra pas le jour avant au moins deux ans, l'approche de Microsoft (nom de code XAML) se révèle très proche de XUL. Elle permettra de piloter Avalon, la nouvelle couche graphique vectorielle de Longhorn, le prochain Windows. Les clients riches bâtis avec XAML se déploieront donc nativement sur Longhorn.

Avec Java Server Faces (JSF), le clan Java se concentre sur les seuls clients légers web, via un langage XML utilisé côté serveur pour produire des pages HTML. Sun tente, d'un autre côté, de répandre son JRE 1.4 (Java Runtime Environment), un socle d'exécution de client riche encore incomplet. Mais il commence à être concurrencé par le projet Eclipse. Plus qu'une alternative aux outils de développement commerciaux, Eclipse 3.0 propose une plate-forme complète d'exécution pour les clients riches (Eclipse Rich Client Platform) : couche graphique, gestion des menus, copier/coller, gestion des préférences utilisateurs, gestion des droits utilisateurs, impression, etc. L'application s'installe directement sur le poste client par simple copier/ coller ou se déploie en un clic sous la forme d'un plug in Eclipse.

IBM s'allie, lui, à Macromedia, qui vient d'annoncer Flex. Ce serveur de présentation repose sur le langage de description d'interfaces Macromedia XML (MXML). Basé sur MVC, ce serveur s'intercale entre le serveur web et le serveur d'applications J2EE pour créer à la volée des interfaces clients Flash. Contrairement à ses concurrents, Macromedia utilise donc la description XML de l'application uniquement du côté serveur. Le plug in Flash installé sur le poste utilisateur joue ensuite le rôle de socle d'exécution de client riche, au même titre qu'un navigateur Mozilla interprète un fichier XUL.

« Cette évolution effrénée conforte l'idée que la couche de présentation des applications est une couche jetable, forcément moins pérenne que la couche de service métier. D'où l'intérêt de les découpler et d'utiliser une approche RAD pour la couche graphique », conclut Sami Jaber.