Rich Internet application

Les applications Web traditionnelles s'articulent souvent sur une architecture utilisant des clients légers : les traitements sont réalisés sur le serveur (distant), le client (local) ne faisant qu'en réaliser une présentation (exemple : HTML). Le client envoie ses données au serveur, celui-ci effectue le/les traitement(s) puis une page de réponse est renvoyée au client. Le serveur est donc sollicité à chaque interaction, hormis quelques cas spécifiques comme la saisie dans un formulaire.

Les RIA s'efforcent de rapatrier chez le client (local) une partie des traitements normalement dévolus au serveur. Le langage Javascript, en particulier, a été conçu dans cette optique. Il permet par exemple d'indiquer au fur et à mesure de la frappe le nombre de caractères qu'il est encore possible de saisir, dans un champ de texte de taille limitée, plutôt que de tout accepter et de renvoyer ensuite seulement un message d'erreur du serveur avec perte d'une partie du contenu frappé.

Les standards Internet ont évolué lentement et continuellement à travers le temps pour s'accommoder de ces techniques. Aussi est-il difficile de définir clairement ce qui constitue une RIA et ce qui n'en constitue pas une. Généralement, ce qui peut être effectué au moyen d'une RIA est limité par les capacités du système client.

Parce que les RIA utilisent les ressources du système client, elles offrent aux applications Web des possibilités d'interfaces utilisateur réactives, ce qui serait impossible avec des balises HTML standards.

On peut déporter sur le client de nombreuses fonctionnalités, comprenant le glisser-déposer, l'utilisation de barres d'outils pour modifier les données, des calculs (par exemple : taux d'intérêt pour un prêt), données n'ayant pas nécessairement besoin d'être renvoyées au serveur.

Le développement d'HTML5 est parfois annoncé comme voué à remplacer ces RIA, en réalité il ne prendra vraisemblablement en charge que les usages et fonctionnalités les plus usitées et répandues des principaux RIA, auxquels l'aspect propriétaire confère une longueur d'avance à un consortium tel que le W3C.

Bien que le développement d'applications s'exécutant dans un navigateur Web en limite la portée, bien que ce soit une tâche difficile à mettre en œuvre, et bien que l'on ajoute un degré de complexité supplémentaire pour développer des applications équivalentes aux applications bureautiques classiques, ces efforts sont souvent récompensés parce que :

• Aucune installation n'est nécessaire — la distribution et la mise à jour de l'application est un processus instantané, invisible et non maitrisable pour l'utilisateur ;
• Les utilisateurs peuvent utiliser l'application depuis n'importe quel ordinateur équipé d'une connexion Internet et d'un navigateur récent ;
• Étant donné que l'utilisation du Web s'accroît, les utilisateurs d'ordinateur sont de moins en moins enclins à installer de nouveaux logiciels lorsqu'une alternative se basant sur le navigateur (qu'il ne faudra pas installer) est disponible.

Ce dernier point est généralement vrai, même si cette alternative est lente ou qu'elle est dépouillée. Un bon exemple de ce phénomène est l'utilisation du webmail.

Le client est un navigateur qui est compatible Javascript, CSS, et capable d'utiliser les fonctionnalités du système d'exploitation par la gestion de plug in (moteur multimedia/3D Quicktime, Windows Media, Unity, RealPlayer, Shockwave). Cette compatibilité Javascript permet l'utilisation des « applets ».

• Netvibes, un portail Web français personnalisable ;
• Zimbra solution open source de bureau mobile ;
• Flickr de Yahoo!, la gestion de photo ;
• Gmail par Google, courriel ;
• Google Maps par Google, des cartes interactives ;
• Deezer, site français d'écoute musicale par abonnement ;
• Fnac.com, solution OpenLaszlo dans l'aide au choix sur les produits.

• Les technologies fonctionnant sur une machine virtuelle (XULRunner) ou sur ajax évoluent tous pour supporter des protocoles de communication basés sur XML (JSON) et des interfaces décrites avec XML. L'utilisation du format XML au niveau de l'interface ouvre la voie du graphique vectoriel (rendu vectoriel tel que SVG, WPF, du XAML, flash, XUL, Swing). L'adoption d'une technologie est fortement liée à la productivité et donc à l'environnement de développement et graphique.

Les applications sont téléchargées depuis un navigateur sur le système d'exploitation et s’exécutent en dehors du navigateur, contrairement à une applet Web qui s’exécute dans le navigateur. En outre, le logiciel charge toujours les versions les plus récentes des applications, et permet ainsi d'éviter les procédures complexes d'installation ou de mise à niveau. Cette approche permet de construire des applications riches sans les limitations du HTML et sans les contraintes spécifiques des différents navigateurs. Cette technique permet aussi de faire des développements à moindre coût par rapport à un développement Web.

L'approche ultra light client met à disposition du développeur une bibliothèque Java qui permet de développer des rich Internet applications entièrement basées sur Java.

L'architecture proposée, entièrement ouverte, est basée sur le protocole half object protocol (HOP) qui permet, au travers d'un ensemble d'interfaces de programmation (API), de déplacer au niveau du serveur Web les données et de ne transférer sur le poste client que les données visuellement disponibles pour l'utilisateur.

Seul le moteur de présentation s'exécute du côté client, ce qui allège d'autant la taille des modules devant être téléchargés depuis le serveur. Cela permet à l'utilisateur d'accéder aux données de son entreprise depuis différents terminaux comme son ordinateur de bureau, son ordinateur portable ou son smartphone.

Elle permet donc de tirer profit à la fois des avantages de la plate-forme client de Java et des avantages de la plate-forme Serveur de java.