Introduction à Ajax

Comme esquissé dans les sections précédentes, les développeurs avaient besoin d'un moyen pour développer des applications interactives, tout en étant en mesure de déployer ces applications sur le Web. Ajax répond exactement à ce besoin. Par exemple, les développeurs peuvent utiliser Ajax pour fournir une fonctionnalité d'auto-complétion qui récupère et affiche des suggestions appropriées que les utilisateurs tapent dans un champ de saisie. Ils peuvent également écrire des applications puissantes de discussions sur le Web qui n'ont pas besoin de rafraîchir la page entière lorsque l'utilisateur tape un nouveau message. Ajax fait tout cela à l'aide de JavaScript dans le navigateur pour modifier l'interface utilisateur directement, en utilisant l’objet XMLHttpRequest pour communiquer avec le serveur sans avoir à rafraîchir la page entière. Ensuite, il utilise les informations renvoyées

Chapitre 5 : Conception d’un système collaboratif pour la planification

107

par le serveur, généralement au format XML ou tout autre format texte, pour mettre à jour l'interface utilisateur.

5.3.1. Notion de l’asynchrone

Afin de comprendre la différence principale entre Ajax et les applications typiques qui ont été développées avant Ajax, nous devons examiner de plus près la façon dont les utilisateurs interagissent avec les applications web.

La Figure 5.2 illustre ça pour une application web typique. L'utilisateur commence par demander une page web. Le serveur traite la demande et renvoie le résultat au navigateur, où il est ensuite remis à l'utilisateur. Une application web typique permet alors à l'utilisateur de faire seulement un nombre limité de choses. L'utilisateur peut fournir des données d'entrée en utilisant les widgets de forme (en cliquant sur un lien ou un bouton pour soumettre l'information), ou en demandant une nouvelle page. Le résultat de chaque action est que l'utilisateur doit attendre que le serveur retourne une réponse. Pendant ce temps, l'utilisateur ne peut plus utiliser l'application. C'est ce que nous appelons un modèle d'interaction synchrone. Toutes les interactions de l'utilisateur s’arrêtent jusqu'à ce que le serveur renvoie une réponse, et alors seulement que l'utilisateur peut continuer à utiliser l'application.

Figure 5.2. Modèle d’interaction d’une application web typique

Bien que ce modèle soit acceptable pour naviguer sur des pages web, il n’est pas pratique pour des applications qui sont quotidiennement utilisées, comme les feuilles de calcul et les logiciels de traitement de texte. Dans le cas d'une application de feuille de calcul, modifier une valeur et ensuite attendre que le serveur retourne le résultat d'une formule recalculée est inacceptable. Tout d'abord, nous voulons continuer à interagir avec la feuille de calcul alors que le résultat de l'action est recalculé. Mais plus important encore, nous voulons aussi éviter

Chapitre 5 : Conception d’un système collaboratif pour la planification

108

de recevoir et d’afficher toute la page chaque fois pour afficher le résultat d’un formule. Cela donne une charge supplémentaire, car le serveur doit régénérer la totalité de la page. Cette dernière est entièrement envoyée sur le réseau, et le navigateur doit afficher la page en complet à nouveau.

Il serait tellement mieux si nous pouvions mettre à jour uniquement les cellules correspondantes dans la feuille de calcul. C'est là que le modèle asynchrone entre en jeu, emportant les lacunes dans l'interaction et permet à l'utilisateur de continuer à interagir avec l'application tandis que les actions précédentes sont gérées par le serveur. Ce modèle est illustré dans la Figure 5.3.

Le problème avec l'interaction montrée dans la Figure 5.3, c'est que ça casse le modèle web classique des requêtes Http pour les pages HTML, dont la simplicité est l'une de ses plus grandes forces. La façon de le faire sans perdre plus que ce que nous gagnons est d'introduire un moteur Ajax, qui est une couche entre l'interaction avec l'utilisateur et le serveur de communication. Ce moteur fonctionne à l'intérieur du navigateur et délègue les actions au serveur tout en gérant les résultats reçus. Parce que ce moteur envoie les appels vers le serveur et pousse (le mot technique anglais est push) les résultats à l'utilisateur, ce dernier peut continuer à interagir avec l'application entre-temps. Parce que le moteur respecte les mêmes standards, et le modèle web reste intact.

Chapitre 5 : Conception d’un système collaboratif pour la planification

109

Pour mettre en œuvre ce modèle asynchrone, nous avons besoin d'un moyen pour envoyer des requêtes au serveur d’une façon asynchrone, sans avoir à faire un rafraichissement de la page. Le web a été initialement conçu pour lier les documents ensemble et naviguer entre eux. Par conséquent, le web et ses normes ne soutiennent pas directement les opérations Ajax. Cependant, parce que les développeurs sont des gens créatifs, et s’il y a un moyen, il sera utilisé pour trouver une solution. Il s'est avéré qu'il y avait un moyen de faire ces appels asynchrones à partir du navigateur, seulement n’est pas d'une manière indépendante du navigateur.

Microsoft Internet Explorer est équipé d'un contrôle ActiveX (XmlHttpRequest) qui pourrait être utilisé pour effectuer un appel asynchrone. Mozilla Firefox contient son propre mécanisme similaire, idéalement aussi appelé XmlHttpRequest, seulement implémenté comme un objet natif. Les deux mécanismes sont similaires dans la façon dont nous les utilisons. Cela a permis aux développeurs d'appliquer ce modèle asynchrone dans des applications qui fonctionnent dans la plupart des navigateurs. Tout ça a fait rapidement d’Ajax une technologie très populaire.

5.3.2. Avantages et inconvénients des applications Internet riches

Nous allons examiner dans cette section les avantages et les inconvénients des interfaces internet riches par rapport aux applications web classiques et les applications de bureau. Dans les sections précédentes, nous avons déjà abordé certains d'entre eux.

a. Avantages

A côté des avantages intrinsèques évidents de l’utilisation des applications Internet riches, ces dernières sont également livrées avec les avantages supplémentaires suivants :

• Aucune installation n’est requise : l’application est téléchargée automatiquement et exécutée à l'intérieur du navigateur. Le logiciel qui gère effectivement l'application est déjà installé sur la machine cliente (navigateur web).

• Les mises à jour sont automatiques : les nouvelles versions de l'application sont également téléchargées automatiquement en simplement revisitant la page web de l'application.

• Indépendance vis-à-vis les Plate-forme : une application Internet riche peut

potentiellement fonctionner sur toutes les plateformes et les systèmes d'exploitation, dans la mesure où elles disposent d'un navigateur et une connexion Internet.

• Plus sécurisées : les applications s'exécutent dans l'environnement restreint d'un navigateur web et sont donc beaucoup moins susceptibles d'être nocives que les applications qui doivent être installées.

Chapitre 5 : Conception d’un système collaboratif pour la planification

110

• Plus de réactivité : puisque toutes les actions des utilisateurs n’exigent pas une communication avec le serveur, les applications Internet riches ont tendance à être plus réactives que les applications web classiques.

• Scalabilité : une grande partie du travail de calcul ainsi que la tenue d'état peut être déchargée vers le client, de sorte que le serveur peut gérer bien plus d'utilisateurs. Il n'a plus besoin de maintenir l'état, ou du moins pas autant qu’avant.

• Efficacité supérieure du réseau : dans les applications web classiques, chaque action de

l'utilisateur nécessite du serveur qu’il régénère et envoie la totalité de la page sur le réseau. Dans le cas d'une application Internet riche, la page web est envoyée en entier une seule fois seulement. Toutes les autres requêtes envoyées au serveur nécessitent seulement les données effectives qui vont être envoyées au client.

b. Inconvénients

Avec toute bonne chose, il y a quelques inconvénients. La même chose vaut pour Ajax et les applications Internet riches. Voici quelques-unes de ces limitations:

• Nécessitent JavaScript ou un plug-in spécifique : parce que l'application entière traverse l'interpréteur JavaScript sur le client. Ce qui se produise lorsque l'utilisateur désactive JavaScript complètement, est que généralement, l'application fait peu ou rien. Évidemment, il est possible d'avoir un plan de sauvegarde pour les utilisateurs, mais alors nous devons maintenir deux applications séparées, ce qui est loin d'être idéale.

• Aucun accès aux ressources système : comme les applications Ajax fonctionnent dans un navigateur, elles sont limitées dans les ressources auxquelles elles peuvent accéder. Par exemple, une application Ajax ne peut pas accéder au système de fichiers client.

• Indexation difficile sur les moteurs de recherche : parce que la plupart des moteurs de recherche ne prennent pas (encore) en charge des applications qui font des mises à jour partielles des pages ou si elles utilisent des plug-ins tels que Flash, la plus part des applications Internet riches sont mal indexées par les moteurs de recherche. Les plus grands moteurs de recherche ont l’intention d'améliorer l’indexation de ce genre d'applications comme leur popularité augmente, mais il sera toujours difficile de les indexer efficacement.

• Dépendance d'une connexion Internet : comme ces applications sont servis à partir du

web et s'exécutent dans le navigateur, elles ont besoin d'au moins une connexion Internet initiale. Mais même pendant l'utilisation, une connexion Internet est nécessaire pour communiquer avec le serveur. Lorsque la connexion n’est (temporairement) pas disponible, la majorité des applications Internet riche cessent de fonctionner. Cependant, il y a des tentatives pour utiliser les services locaux fournis par le navigateur pour le stockage temporaire dans le cas où une connexion Internet n’est pas disponible.

Chapitre 5 : Conception d’un système collaboratif pour la planification

111

5.3.3. Utilisation d’Ajax

En se basant sur les avantages et les inconvénients décrits dans la section précédente, nous croyons fermement que les applications Internet riches ne sont pas adaptées pour toutes les applications. Mais il y a des directives précises quant au moment de construire une application Internet riche et quand s'en tenir à développer des applications web classiques. Considérons les cas suivants :

• Nous voulons développer une application que les utilisateurs ont besoin quotidiennement, et ils passent beaucoup de temps en l’utilisant.

•Les tâches entreprises s'appuyant sur la rétroaction directe de l'application pour améliorer la productivité.

• La plupart, sinon la totalité, de l'application requiert une authentification des utilisateurs, alors que l’indexation par les moteurs de recherche n'est pas donc une priorité.

Nous pensons que si les besoins des utilisateurs répondent à ces conditions, les applications Internet riche sont fortement conseillées.