I. Définition▲
Il est compliqué de définir aujourd'hui le terme client riche. Utilisé par de nombreux éditeurs pour leur solution au goût du jour, il est difficile d'en trouver une définition claire. Je me suis donc prêté à cet exercice en m'appuyant sur tout ce que l'on peut lire sur le sujet dans les médias, mais aussi, et surtout sur mon expérience acquise lors de divers projets web.
Un client riche, c'est :
- une technologie permettant de développer la couche présentation d'une application ;
- la disparition du développement d'application en mode « page » ;
- très bien pourvu en composants graphiques de haut niveau ;
- facilement déployable et « upgradable ».
Si la définition ci-dessus se veut assez générale, on peut classifier les clients riches en deux grandes familles : les « Rich Internet Applications » et les « Rich Desktop Application ».
Ces deux catégories désignent clairement deux types de solutions distinctes sur un point bien précis : la nécessité d'installer (ou pas) un environnement d'exécution quelconque sur le poste client (environnement qui se résume à un simple navigateur dans le cas des RIA). Pour être plus pragmatique, on dira qu'un client riche doit allier à la fois les qualités de déploiement des applications web actuelles, avec la richesse de l'ergonomie des applications de type client lourd.
Attention, le terme client riche couvre simplement la technologie permettant d'implémenter la couche de présentation (encadré sur le schéma d'architecture Architecture n-tiers traditionnelle) ! Le terme client riche n'inclut pas le middleware à utiliser pour faire le lien avec le serveur ! L'impact que peut avoir cette partie-là est tel que nous lui consacrerons un chapitre.
II. Les clients riches « RIA »▲
II-A. XUL▲
À tout seigneur, tout honneur !
Précurseur dans le domaine, XUL est un langage XML de description d'interface graphique. Il est nativement mieux pourvu en composants graphiques de haut niveau que le HTML, et utilise, un modèle de programmation événementiel pour gérer les actions de l'utilisateur (un clic sur un bouton par exemple) : JavaScript et bientôt python. Un point très positif est surtout la qualité de l'intégration de ces deux langages.
XUL a été initialement conçu pour fonctionner dans un navigateur web, à la sauce RIA. L'évolution technologique aidant, des extensions le rapprochant du principe RDA sont en train d'apparaître.
<hbox flex="1" id="main-box">
<vbox>
<!-- Tree Overlay -->
<tree id="result-tree"/>
<!-- Details Overlay -->
<hbox id="detail-box"/>
<separator class="groove"/>
<!-- Price Overlay -->
<hbox id="price-box" />
</vbox>
<splitter id="detail-comment" collapse="after" resizeafter="grow">
<grippy />
</splitter>
<!-- Extra Info right panel -->
<tabbox flex="1" id="extra-info-tab">
<tabs id="comment-tab">
<tab label="&info.label;"/>
<tab label="&review.label;"/>
</tabs>
<tabpanels style="background-color: White;" flex="3">
<tabpanel>
<iframe id="allInfo-selected" src="html/allinfo.html" flex="3" />
</tabpanel>
<tabpanel>
<iframe id="comment-selected" src="html/comment.html" flex="3"/>
</tabpanel>
</tabpanels>
</tabbox>
</hbox>II-B. Ajax : Asynchronous Javascript and Xml▲
AJAX est le nom donné à une technique de conception de nos pages HTML. Cette technique est loin d'être novatrice : elle fut en effet initiée par Microsoft il y a quelques années maintenant.
Le principe de base d'AJAX se résume en un mécanisme visant à éviter de mettre à jour la page HTML complète à chacune des interactions utilisateur. On est en droit de se poser la question de savoir s'il s'agit véritablement d'un besoin pour améliorer la qualité des interfaces utilisateur… La réponse est sans équivoque : oui. Quelle application de gestion n'a pas besoin de mettre à jour un tableau HTML suite à une action d'un utilisateur ? Peu, voire aucune !
Initialement, les technologies HTTP et HTML ne permettaient d'associer qu'une seule action au clic d'un utilisateur sur un bouton : l'envoi d'une requête HTTP vers le serveur web, requête à laquelle le serveur répondait en régénérant une page HTML contenant le tableau mis à jour. Le navigateur, à réception de cette réponse, se contentait d'effacer la page actuellement à l'écran pour la remplacer par la nouvelle. Cela sous-entend donc que la réponse du serveur web contiendra bien les nouvelles données du tableau, mais elle inclura aussi l'ensemble des informations de présentation de la page le contenant.
Les problèmes qu'induit ce fameux mode page, sont :
- un « scintillement » de l'interface graphique HTML à chaque nouvel événement utilisateur ;
- la nécessité d'implémenter des mécanismes de « mémento » de façon à ce que les champs annexes au tableau soient restitués tels qu'ils étaient préalablement.
AJAX permet donc de compléter ce mécanisme : tout événement sur les composants graphiques du client pourra se voir associer un comportement particulier. Ce comportement pourra être l'envoi d'une requête vers le serveur, mais surtout une régénération partielle d'une partie de la page HTML avec les informations qu'il recevra en retour (dépourvues de toute information de présentation).
AJAX remplace le comportement naturel du navigateur en implémentant lui-même l'action associée à l'événement sur l'IHM et va se charger d'envoyer une requête HTTP au serveur web. Mais, contrairement à une page HTML standard, ce n'est pas le navigateur qui va recevoir la réponse, mais la couche AJAX qui va simplement aller modifier le code HTML de la page courante afin de mettre à jour uniquement la partie correspondant au tableau !
Techniquement, AJAX n'est en fait que l'utilisation conjointe d'un certain nombre de technologies existantes :
- JavaScript pour intercepter les événements et envoyer la requête au serveur web ;
- JavaScript + DOM pour récupérer le résultat et modifier le contenu de la page courante en modifiant l'arbre DOM qui lui est associé.
Si l'on regarde la signification de l'acronyme AJAX, le X représente XML, et fait référence au format des données que l'on peut envisager d'utiliser pour permettre au serveur web d'alimenter les requêtes en provenance de la couche AJA ? Ce point-là sera approfondi dans le dernier chapitre.
II-C. JSF et Atlas▲
Il est difficile d'évoquer AJAX sans évoquer un certain nombre de problèmes qui risquent de découler de son utilisation (nous avons déjà un retour d'expérience sur l'utilisation des technologies JavaScript, CSS, DOM et HTML). Parmi ces problèmes, on peut en retenir deux :
- la complexité des pages : un mélange HTML, DOM, JavaScript rend difficile le débogage ainsi que la maintenance évolutive et corrective ;
- une réutilisation des composants « ajaxisés » assez délicate et finalement assez limitée.
Microsoft proposera dans la prochaine version de « Visual Studio » un certain nombre de composants incluant des comportements de type AJAX. Dans le monde Java, le framework JSF permet la même chose, à la différence qu'il s'agit d'un framework extensible, qui vous permet donc de capitaliser sur des composants correspondant à vos besoins spécifiques.
Ces frameworks nous permettent donc d'espérer pouvoir répondre favorablement aux points négatifs cités précédemment en rendant le processus de développement des pages HTML beaucoup moins technique et plus assisté par les outils de développement.
III. Flash : un candidat sérieux▲
Tout le monde connaît Flash (Adobe) comme l'outil permettant de développer des petites animations qui « égayent » vos pages web. Il fonctionne suivant le principe d'un plugin du navigateur web qui doit être installé sur le poste qui va l'exécuter. L'image que l'on se fait de Flash est maintenant obsolète ! Il est désormais devenu un outil de développement d'interface homme machine pourvu de composants graphiques de haut niveau (onglet, menu, menu déroulant…), et d'un look très séduisant. Il bénéficie de plus d'un mécanisme de déploiement hérité de ses versions précédentes : simplement téléchargé par un navigateur et exécuté par le plugin Flash (installé sur 95 % des postes connectés à Internet).
Plusieurs technologies permettent aujourd'hui de développer une application Flash, les principales étant :
- FLEX (Adobe). Payant. Pourvu d'un environnement de développement wysiwyg ;
- Laszlo. Open Source. Un outil de développement est fourni par IBM sous forme d'un plugin d'Eclipse.
Les deux solutions proposent finalement le même type de résultat : une application Flash. Ils se différencient simplement sur leurs propriétés intrinsèques, à savoir leur coût de licence, la qualité de l'outillage qui leur est associé…
IV. Les clients riches « RDA »▲
Plusieurs technologies partent sur une solution technique bien plus radicale : la fin de l'utilisation du navigateur web comme « conteneur d'application ». Mais, si le navigateur web n'est plus utilisé pour télécharger et afficher la couche de présentation, qui s'en charge ?
La réponse à cette question dépend de la technologie choisie. En tout état de cause, il est nécessaire que ce nouveau conteneur soit installé sur le poste qui exécutera l'application, rendant non accessible l'application depuis un poste banalisé. Attention de ne pas assimiler le conteneur à l'application ! Le conteneur fournira un socle d'installation et déploiement, de mise à jour et d'exécution aux futures applications.
Parmi les solutions techniques de type RA qui tiennent le haut de l'affiche, l'une des principales est celle d' « Eclipse RCP » (« Rich Client Platform ») ; on trouve aussi une version « desktop » du produit FLEX vu précédemment, ainsi qu'à un niveau plus avancé le futur système d'exploitation Windows (nom de code « vista »), qui intègre directement le moteur de rendu dans le système d'exploitation.
V. Les middlewares dans tout cela ?▲
Si l'on constate que tout le monde s'agite sur les technologies client riche, une petite part seulement de cette agitation concerne le middleware qui sera utilisé par cette interface cliente pour dialoguer avec la couche applicative qui demeure physiquement sur le serveur d'application.
HTTP semble le protocole réseau incontournable dans l'architecture générale mise en œuvre par une solution de type client riche. Compatible avec les problématiques de déploiement, son adoption ne nécessite pas de grand changement en ce qui concerne l'infrastructure serveur, et l'utilisation de HTTPS permet de mettre en œuvre un dialogue crypté entre le client et le serveur, et ce, de façon aisée. Il reste maintenant à déterminer ce que l'on va faire passer dessus, et là, plusieurs solutions sont envisageables :
V-A. Les webservices▲
Les webservices se placent ici en grandissimes favoris… L'utilisation d'une pile SOAP sur le client permet d'envisager une interopérabilité satisfaisante entre le client et le serveur, en particulier lorsque ces deux couches ne sont pas implémentées avec les mêmes technologies. Quelques lacunes d'interopérabilité sont néanmoins à gérer, notamment en ce qui concerne la gestion de l'authentification, ainsi que la mise en œuvre de discussions « transactionnelles » entre le client et le serveur.
Un mode dégradé peut aussi convenir : l'utilisation des web services sans utiliser SOAP, mais en véhiculant simplement des flux XML dont on aurait la maîtrise côté client et côté serveur.
V-B. JSON▲
JSON est un modèle de décomposition d'information de façon structurée, mais moins verbeuse que XML. Son utilisation nécessite l'emploi d'un parseur (il existe un parseur développé dans de nombreux langages, ce qui laisse espérer une interopérabilité réelle).
V-C. Format propriétaire ?▲
Reste encore la possibilité d'utiliser un protocole totalement propriétaire entre le client et le serveur. Cette solution peut d'ailleurs être utilisée avec Flex afin de véhiculer des données préformatées entre le client et le serveur (un « datagrid » par exemple).
VI. Conclusion▲
On ne peut pas remettre en cause aujourd'hui la nécessité de faire évoluer les technologies clientes. Les solutions proposées demeurent techniquement différentes et à des degrés de maturité inégaux. Un frein risque d'apparaître sous peu pour le développement d'applications véritablement performantes : le sacro-saint protocole HTTP qui, de par son mode déconnecté, ne favorise pas (voire limite) la mise en œuvre d'application fortement transactionnelle et/ou sécurisée !
VII. Remerciements▲
Cet article a été mis au gabarit de developpez.com : voici le lien vers le PDF d'origine : AR02-ClientRiche-Article.pdf.
L'équipe Java de Developpez.com tient à remercier la société Valtech pour la mise à disposition de cet article aux membres de Developpez.com.
Nous tenons à remercier également ced pour sa relecture attentive de cet article et Régis Pouiller pour la mise au gabarit.