Dossier Technique : LES CLIENTS RICHES

LEFEBVRE Benoit
LIANI Samir
IMA3i
Dossier Technique : LES CLIENTS RICHES
Responsable : Olivier Caron
Année 2006-07
SOMMAIRE
Introduction ..................................................................................................................................... 03
1. LES CLIENTS RICHES ...................................................................................................................... 04
1.1. Principe de fonctionnement ............................................................................................ 04
1.2. Les différentes technologies ............................................................................................ 05
1.2.1. Les « Rich Internet Applications » ....................................................................... 05
1.2.2. Les « Rich Desktop Applications » ....................................................................... 05
2. UN PREMIER EXEMPLE : AJAX ...................................................................................................... 07
2.1. Principe de fonctionnement ............................................................................................ 07
2.2. Avantages et inconvénients ............................................................................................ 09
3. UN SECOND EXEMPLE : XUL ......................................................................................................... 11
3.1. Caractéristiques ................................................................................................................ 11
3.2. Organisations d’une fenêtre XUL ..................................................................................... 11
3.3. XUL et les autres technologies d’interface graphique ..................................................... 12
3.4. Avantages et inconvénients ............................................................................................. 13
Conclusion ....................................................................................................................................... 14
Références ........................................................................................................................................ 15
2
INTRODUCTION
De nombreuses applications fonctionnent selon un environnement client/serveur, cela signifie que
des machines clientes (faisant partie du réseau) contactent un serveur, une machine généralement très
puissante en terme de capacités d'entrée-sortie, qui leur fournit des services. Ces services sont des
programmes fournissant des données telles que l'heure, des fichiers, une connexion, etc.
Les services sont exploités par des programmes, appelés programmes clients, s'exécutant sur les machines
clientes. On parle ainsi de client lorsque l'on désigne un programme tournant sur une machine cliente,
capable de traiter des informations qu'il récupère auprès d'un serveur.
On peut alors distinguer trois types de clients :
Le terme « client lourd » désigne une application cliente graphique exécutée sur le système
d’exploitation de l'utilisateur. Il possède généralement des capacités de traitement évoluées et souvent une
interface graphique sophistiquée permettant d'offrir une grande ergonomie grâce au multifenêtrage ou
encore au « drag & drop ». Néanmoins, ceci requiert un effort de développement et tend à mêler la logique
de présentation (l'interface graphique) avec la logique d’application (les traitements).
Ce type d'application étant généralement installé sur le système d'exploitation de l'utilisateur, une nouvelle
version doit être installée afin de la faire évoluer. Pour y remédier, les éditeurs d'applications lourdes les
dotent généralement d'une fonctionnalité exécutée au lancement de l'application, permettant de vérifier sur
un serveur distant si une version plus récente est disponible et le cas échéant propose à l'utilisateur de la
télécharger et de l'installer.
Le terme « client léger » s’oppose au client lourd et désigne une application accessible via une
interface web consultable à l'aide d'un navigateur web grâce au protocole de communication HTTP, où la
totalité de la logique métier est traitée du côté du serveur. Pour ces raisons, le navigateur est parfois appelé
client universel. Le fait que l'essentiel des traitements soit réalisé du côté du serveur et que l'interface
graphique soit envoyée au navigateur à chaque requête permet une grande souplesse de mise à jour.
Cependant, ce modèle montre ses limites. L'origine du terme « léger » provient de la pauvreté du langage
HTML, qui ne permet de faire que des interfaces relativement pauvres en interactivité, l'ergonomie de
l'application possède un champ réduit : il est impossible de gérer les opérations contextuelles, le
multifenêtrage. De plus, l'application doit s'affranchir des différences d'interprétation du code HTML par les
différents navigateurs.
Un « client riche » est un compromis entre le client léger et le client lourd. L'objectif du client riche
est donc de proposer une interface graphique permettant d'obtenir des fonctionnalités similaires à celles
d'un client lourd (« drag & drop », onglets, multifenêtrage, menus déroulants) et dont l'essentiel des
traitements est géré du côté du serveur.
L’objectif de ce dossier est d’effectuer un tour d’horizon des technologies actuelles permettant de
définir une application riche. Nous en profiterons pour étudier plus en détails les exemples d’Ajax et de XUL.
3
1. LES CLIENTS RICHES
1.1 Principe de fonctionnement
Le déploiement d’une application riche s'effectue comme une page web : sur le simple appel d'une
URL, un fichier XML généré à la volée est interprété par un socle d'exécution installé sur le poste de
l'utilisateur tel que le framework .NET de Microsoft, le Java Runtime Environment de Sun ou le navigateur
Mozilla. Ce socle contient toutes les fonctions génériques utilisées par une application : sécurité,
communication avec le serveur, cache de données locales, composants graphiques de l'interface, etc. On
peut facilement le comparer à un navigateur internet très évolué.
Comme pour une page HTML, le développeur assemble des composants graphiques pour créer
l'écran. Il indique également quels sont les services web à appeler lorsque l'utilisateur clique sur un bouton.
Mais seules la description des écrans, la cinématique de l'application, et les données transitent au format
XML, entre le client et le serveur. Contrairement à une architecture web, les éléments graphiques de
l'interface sont déjà pré installés avec le socle d'exécution. Ce dernier interprète la description des écrans et
la cinématique pour afficher l'application. Un client riche n'est donc constitué au final que d'un ensemble de
fichiers XML interprétés sur le poste client. Un processus en tout point identique à l'affichage d'une page
web dans un navigateur standard.
Le poids des échanges entre le client et le serveur est proche de celui d'un client lourd, car les flux
XML peuvent être compressés. Il est en revanche bien plus faible que celui d'un client léger pour lequel
l'ensemble de l'interface utilisateur (page HTML) est transmis à chaque changement d'écran.
A - Le socle d'exécution interprète le fichier XML. Il génère l'écran puis appelle les services Web sous-jacents pour alimenter
l'interface en données. Il les interroge en fonction des données saisies par l'utilisateur. Il peut éventuellement stocker des données
en local pour permettre à ce dernier de travailler en mode déconnecté
B - Le serveur de présentation envoie la description de l'application (écrans + cinématique) au serveur d'exécution.
C - Le ou les services Web récupèrent les paramètres fournis par le client riche. Ils effectuent leurs calculs et renvoient les données
correspondantes.
4
1.2. Les différentes technologies
On peut classer les clients riches en deux grandes familles : d’une part, les clients Internet (« Rich
Internet Applications ») et d’autre part, les clients autonomes (« Rich Desktop Applications ») davantage
destinés aux applications d’entreprise. La principale différence entre les deux familles réside dans la
nécessité ou non d’installer un socle d’exécution sur la machine cliente. Dans le cas des clients Internet, ce
socle d’exécution est tout simplement un navigateur web standard.
1.2.1. Les « Rich Internet Applications »
Ce sont des applications dynamiques pour Internet vers lesquelles tout le monde semble tendre
assez naturellement.
Les principaux standards permettant de définir de telles applications sont les suivants :
•
XAML, proposé par Microsoft et XUL proposé par la fondation Mozilla : ce sont des standards XML,
utilisés notamment dans les applications utilisant le framework .NET pour XAML et dans le client de
messagerie Mozilla Thunderbird ou dans le navigateur Mozilla Firefox pour XUL. Les interfaces XML
sont interprétées par le navigateur et sont liées à un seul navigateur. On peut craindre qu’elles aient
du mal à décoller sur le web pour cette raison. Cela reste par contre une alternative envisageable
pour des développements Intranet. Elles ne sont cependant pas utilisées à grande échelle.
•
Flash, Adobe Flex, OpenLaszlo, standards XML proposés par la société Adobe (ex Macromédia). Ce
sont des interfaces graphiques qui s'exécutent sur le runtime Flash. Cette technologie permet de
réaliser des choses puissantes mais elle impose le plus souvent un investissement important en
terme de formation. Ces solutions sont de fait plus utilisées par les développeurs venant du monde
du design, qui connaissent et maîtrisent déjà les technologies sous jacentes.
•
Ajax, représentant une fusion du Javascript et de XML. Cette technologie avance très vite et rallie à
lui de plus en plus de développeurs. La raison de ce pré succès est simple : Ajax permet de réaliser
des choses puissantes, sans gap technologique pour les équipes de développements déjà en place,
et est multi navigateur.
Les principaux intérêts d'une application de type RIA sont d’offrir une vue unifiée de l’application en une
seule page écran, une communication transparente avec les serveurs d'applications, la possibilité de
sauvegarder/restaurer les données sur le poste client et un attrait visuel non négligeable.
1.2.2. Les « Rich Desktops Applications »
Ce sont les solutions exécutées nativement sur le poste client, sans passer par un navigateur web.
Ces solutions sont incontournables lorsqu’il est nécessaire que l'application pilote des ressources localisées
sur le poste client (périphériques, fichiers, etc.), lorsqu’un usage intensif de la 2D ou 3D temps réel est
5
nécessaire au sein de l’interface graphique ou lorsque de gros volumes de données sont localement
manipulés par l’utilisateur (traitement de vidéo).
Les technologies suivantes font partie de ce type de clients :
•
Eclipse RCP (Rich Client Platform), qui s’inscrit dans Eclipse, projet open source d’environnement de
développement Java, et qui s’exécute sous la forme de plug-in dans le Java Runtime Environment.
•
Workplace Client Technology Rich Edition, proposée par IBM et basé sur Eclipse RCP, notamment
complété par une librairie de composants graphiques.
•
Windows Smart Client, proposée par Microsoft, s'exécutant dans le framework .NET, technologie de
déploiement gérée par Visual Studio.
•
Swing, NetBeans et Java Web Start, proposées par Sun et s’exécutant directement dans le Java
Runtime Environment.
6
2. UN PREMIER EXEMPLE : AJAX
Ajax, pour Asynchronous Java script And XML, est le nom donné à une technique de conception de
pages HTML qui utilise des scripts Java script coté client pour échanger de la donnée avec le serveur Web
sans nécessairement rafraîchir la page Web. 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.
Ajax est en fait seulement un nom donné à un ensemble de techniques préexistantes et qui dépend
essentiellement de la classe XMLHttpRequest. Cette technologie fait également usage de HTML, CSS pour la
présentation de la page, en général XML pour l’échange des données, PHP ou un autre langage de scripts
coté serveur.
Les utilisateurs souffrent de plus en plus de la lenteur des applications Web. Après chaque action il
faut attendre que la page montrant le résultat s’affiche. Ajax permet d’améliorer nettement le confort
utilisateur des applications Web en s’approchant du niveau clients que l’on trouve sur le poste de travail. En
effet, cet ensemble de technologies améliore la réactivité des applications en fournissant une variété de
composants permettant de saisir et de manipuler de l’information plus aisément et souvent de manière
beaucoup plus intuitive.
L’objectif d’Ajax est de permettre d’avoir des applications utilisables à l’aide d’un navigateur Web et
qui satisfont les buts de productivité, de mise en réseau et de maintenance centralisée sans un trop grand
effort. Pour atteindre ce niveau, il faut commencer par penser différemment la façon de créer nos pages
Web ainsi que nos applications.
2.1. Principe de fonctionnement
Le principe de base est d'intercepter en utilisant Java script les évènements survenants sur la page,
et d'insérer dynamiquement dans la page un contenu provenant d'un serveur web toujours en utilisant Java
script. La pierre angulaire de cette méthode est l'objet XMLHttpRequest qui permet à Java script d'effectuer
une requête vers le serveur sans que l'utilisateur ne le voie, et ce de façon asynchrone, c’est-à-dire en
laissant la main à l'utilisateur.
7
La technologie Ajax repose sur les trois principes suivants :
•
Le navigateur héberge une application et non du contenu : lorsque l’utilisateur lance
l’application, des données légèrement plus lourdes seront chargées chez le client. Cependant,
elles y resteront durant toute la session et seules les interactions seront transmises.
•
Le serveur envoie des données et non du contenu : puisque la majeure partie de l’application se
trouve déjà du côté client, ne sont échangées avec le serveur que les données modifiées.
•
L’utilisateur interagit continuellement avec l’application, les requêtes aux serveurs sont
implicites plutôt qu’explicites.
La construction d’une requête « Ajax » s’effectue de la façon suivante :
Il faut commencer par créer une nouvelle instance de l’objet. Selon, le navigateur qui est utilisé, le
constructeur n’est pas le même.
Code : instanciation
if (window.XMLHttpRequest)
request = new XMLHttpRequest();
// Firefox, Safari, ...
else if (window.ActiveXObject)
request = new ActiveXObject("Microsoft.XMLHTTP"); // Internet Explorer
8
On associe ensuite une fonction à l’attribut onreadystatechange de XMLHttpRequest. Cette
propriété est activée par un événement de changement d’état. Dans cette fonction, il faut attendre la
disponibilité des données, et l'état est donné par l'attribut readyState de XMLHttpRequest. Lorsque celui
ci vaut 4, on peut effectuer le traitement : les données fournies par le serveur sont récupérées dans les
champs responseXml ou responseText de l'objet XMLHttpRequest. S'il s'agit d'un fichier XML, il sera
lisible dans responseXml par les méthodes de DOM.
Code : attente et traitement de la réponse
req.onreadystatechange = function()
{
if(req.readyState == 4)
{
// OK, on effectue le traitement
}
else
{
// attente...
}
};
Pour recueillir des informations sur le serveur, la classe XMLHttpRequest dispose de deux méthodes :
open() pour établir une connexion et send() pour envoyer une requête au serveur. La commande pour
la méthode open()peut être GET ou POST et fonctionne comme en php, on spécifie ensuite le fichier dans
lequel écrire ou lire les données, et un flag permet de choisir le mode de communication synchrone (false)
ou asynchrone (true).
Code : requête
req.open("GET", "fic.php?var=value", true);
req.send(null);
ou
req.open("POST", "fic.php", true);
req.send(value);
2.2. Avantages et inconvénients
L’avantage principal des interfaces Ajax est qu’elles offrent une interactivité et une réactivité bien
plus importantes que les pages habituelles, où l'utilisateur doit attendre le rechargement complet de sa
page. Un autre avantage est que côté serveur n'importe quel environnement peut convenir (PHP, GCI,
Servlet, ASP, .Net) puisqu'il suffit de répondre en XML à des requêtes HTTP. Le serveur web ne fournit plus
d'interface utilisateur, mais seulement la couche donnée et la logique métier. Le point fort de l'approche
Ajax est qu'on peut ajouter une interface riche à un site web dynamique existant, quelque soit sa
technologie, en ajoutant une interface XML-RPC côté serveur.
9
En revanche, Ajax peut entraîner des problèmes de latence dépendants du réseau et qui sont mal
perçus et compris par l’utilisateur. L'utilisation d'Ajax peut aussi entraîner une impossibilité pour l'utilisateur
d'utiliser son bouton "Retour" de façon attendue. De la même façon, Ajax pose des problèmes pour la mise
en place de signets sur les pages, ainsi que pour l'indexation du contenu des pages. Enfin, le fait que le
moteur Ajax fait fortement appel au Java script oblige qu’il soit activé sur le navigateur ; il faudra donc
toujours prévoir une solution de repli acceptable.
10
3. UN SECOND EXEMPLE : XUL
XUL, pour XML-based User interface Language, est un langage de description d'interfaces graphiques
basé sur XML. Initialement, XUL a été développé afin de permettre de créer facilement l'interface graphique
du navigateur Web Mozilla. Un moteur XUL est intégré au moteur Gecko de Mozilla. L'inconvénient majeur
de XUL est qu'il ne peut s'exécuter sous Internet Explorer, mais depuis peu il est devenu possible de
télécharger des exécutables autonomes via XulRunner. Il s'agit d'une plate-forme "standalone" d'exécution
de programme, avec laquelle l'utilisateur peut se passer de Firefox pour exécuter un logiciel XUL
3.1. Caractéristiques
XUL comprend un ensemble de balises permettant de définir des boutons, des listes, des menus, ou
encore des zones d'édition, tous les éléments d'une véritable interface utilisateur. Un tel langage facilite le
travail du développeur et permet d'écrire l'interface d'une application aussi aisément qu'une page Web.
Le développement d'une application XUL se rapproche du développement d'une application cliente
ou client-serveur traditionnelle. À chaque objet graphique sont associés des événements (clic de souris,
double-clic, etc) pour lesquels le développeur doit écrire du code (typiquement en Java script) à exécuter par
la machine cliente. L'application peut récupérer des données d'un serveur, par exemple via des requêtes
HTTP.
Le fait de définir dans un document XML la structure de l'interface graphique permet de réutiliser la
même structure d'un environnement à l'autre et même d'un langage de programmation à l'autre.
L'une des grandes richesses de XUL est son extensibilité, et la facilité de réutilisation d'éléments. Il
est possible de définir ses propres balises pour mettre en place des composants complexes et réutilisables
en écrivant un fichier XBL (eXtensible Binding Language). Celui ci comporte, pour chaque nouveau
composant qu'il décrit, une partie décrivant l'aspect graphique du composant, par association des éléments
graphiques de base par exemple, et plusieurs parties décrivant son comportement, sous la forme de
fonctions Java script. Les bindings ainsi définis peuvent hériter les uns des autres, et surcharger leurs
contenus ou comportements.
3.2. Organisation d'une fenêtre XUL
Une fenêtre XUL est conçue comme un emboîtement de « boîtes » rectangulaires. Une boîte
contient des sous-éléments qui sont juxtaposés soit verticalement, soit horizontalement. Ces sous-éléments
peuvent être des champs de type texte, des listes déroulantes, des champs affichant du code html, et ainsi
de suite. Ces sous-éléments peuvent aussi être des boîtes, qui elles-mêmes contiendront d'autres éléments.
À l'intérieur de chaque boîte, divers paramètres permettent de paramétrer facilement l'alignement des souséléments (à gauche, en haut, centré...) ainsi que leur comportement en cas de redimensionnement de la
11
fenêtre (taille fixe, taille proportionnelle...). L'affichage de tous ces éléments graphiques peut être configuré
en utilisant une feuille de style CSS, ce qui facilite l'accès à XUL pour les développeurs Web.
La forme la plus basique d'un fichier XUL est la suivante :
Code : fichier vide.xul
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window id="main-window" title="Fenetre principale"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
</window>
Un fichier XUL ne peut contenir qu'un seul élément <window>, l'ensemble de l'interface de la
fenêtre étant défini entre les balises de cet élément racine. XUL peut être déclaré avec un de ces trois
espaces de nom :
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:rdf = « http://www.w3.org/1999/02/22-rdf-syntax-ns# »
Voici une comparaison entre quelques lignes de code XUL et HTML qui affichent toutes deux le
traditionnel « Hello World ! » :
Code : XUL
<window
mlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<box>
<description>Hello world!</description>
</box>
</window>
Code : HTML
<html>
<body>
<p>
Hello World!
</p>
</body>
</html>
3.3. XUL et les autres technologies d'interface graphique
XUL facilite la mise au point d'une interface plus évoluée que HTML sur le plan ergonomique. En
effet les objets XUL se manipulent via une interface DOM, comme en DHTML. De plus une interface XUL peut
récupérer d'un serveur les seules données nécessaires à la mise à jour d'un élément de la page et non
l'ensemble de la page elle-même ; ces données peuvent être récupérées en XML et de manière asynchrone,
ce qui permet d'utiliser la méthode AJAX en programmation XUL. Ces techniques permettent d'améliorer
12
considérablement les temps de réponse et le confort de l'utilisateur. L'environnement XUL les utilise de
manière transparente pour l'utilisateur dans le système des templates (modèles de page) qui permet de
générer une partie de l'interface utilisateur à partir de données externes en RDF, sans avoir à écrire une ligne
de code Java script.
XUL est aussi un concurrent des technologies client-serveur traditionnelles comme Delphi. XUL offre
par exemple l'avantage d'être basé sur des standards ouverts tels que XML. Toutefois XUL ne bénéficie pas
pour le moment du support d'environnements de développement sophistiqués : il faut écrire ou générer des
fichiers XML pour décrire l'interface graphique.
Exemple Boîte à Widgets Xul:
http://www.chevrel.org/confs/abul06/xul/top.xul
3.4. Avantages et inconvénients
Les plus :
•
Interopérabilité : l'interface riche créée peut être visualisée sur différentes plates-formes. Une
application XUL est automatiquement multi plate-forme : son code fonctionnera sur les différentes
version de Windows, Linux, MacOS.
•
Rapidité de chargement : puisqu'une interface XUL peut récupérer du serveur uniquement les
données nécessaires à la mise à jour d'un élément de la page et non l'ensemble de la page ellemême .
•
Intégration : XUL est basé sur le standard XML et peut donc intégrer d'autres applications XML telles
que SVG. Par ailleurs il peut être utilisé par des applications web transférées par http.
•
Installation facile
Les moins :
•
Navigateur : Il est nécessaire d'utiliser un navigateur Mozilla pour utiliser des applications XUL. Cela
pose problème si celles-ci sont destinées à être utilisées sur le web car Internet Explorer ne sait pas
afficher une page en XUL.
•
Incompatibilité : XUL ne peut être associé au langage XAML développé par Microsoft.
•
Utilisation : XUL est long à décoder et apprendre si le développeur est débutant.
•
Absence de message en cas erreur, l’interface de s’affiche pas.
13
CONCLUSION
L'interface utilisateur est devenue le nouvel enjeu fort du Web. AJAX est une expression de ce
phénomène et préfigure la prochaine grande évolution des interfaces Web. La mise en oeuvre d'AJAX rend
possible un GUI riche et dynamique basé sur Java script (XMLHttpRequest) et permet l'intégration de
données sans recharger entièrement la page. Cependant, AJAX ne résout pas la compatibilité avec différents
navigateurs ce qui ne satisfait pas l'utilisateur final. C'est sans doute pour cela que d'autre interfaces riches,
basées sur le futur XAML (fondement d'Avalon, l'interface graphique de Microsoft Longhorn) ou sur XUL
(Mozilla fondation) commencent à voir le jour.
Mozilla est à consonance XUL et base son prochain chantier sur l’isolation du code encore dépendant
des applications historiques du framework (firefox, thunderbird), de manière à pouvoir créer une machine
virtuelle indépendante du moteur de rendu Gecko permettant d’exécuter des applications XPFE autonomes.
Cette séparation permettra de réduire la taille de l’empreinte mémoire des applications du framework. Les
applications XUL seront alors exécutées comme les applications natives. Cela entraînera une transparence
complète pour l'utilisateur qui ne différenciera plus les applications natives des applications XUL, les
applications locales des applications Web.
14
REFERENCES
http://robin.sourceforge.net/ (Exemple de XUL)
http://sicwww.epfl.ch/SIC/SA/SPIP/Publications/IMG/pdf/4-6-page1.pdf
http://solutions.journaldunet.com/0412/041217_tribune.shtml
http://www.zdnet.fr/entreprise/service-informatique/serveurs-stockage/0,50007198,39150184,00.htm
http://www.atelier.fr/article.php?catid=26&artid=29085
http://www.01net.com/article/231067.html
http://www.indexel.net/1_6_4320__3_/15/89/1/Client_riche___de_nombreuses_technologies_concurrentes
.htm
http://www.xul.fr/xml-ajax.html
http://xulfr.org/
http://www.clever-age.com/spip.php?page=article&id_article=323
http://developpeur.journaldunet.com/tutoriel/xml/030606xml_xul1.shtml
http://javascript.developpez.com/faq/?page=Ajax
15