# Plateforme client riche

Une plateforme client riche (en anglais Rich Client Platform ou RCP) permet le développement de clients riches.

## Historique
### Jusqu'en 2000 : les applications classiques, les clients lourds et le modèle client-serveur

Les applications sont conçues selon deux modèles : les applications classiques qui ne nécessitent pas de réseau pour fonctionner et, avec la généralisation des réseaux, les applications client-serveur qui permettent de travailler sur les mêmes données depuis des machines distinctes. Inconvénients : ces applications requièrent l'installation d'une application (parfois appelée client lourd) sur les postes utilisateurs. Elles compliquent la gestion des postes utilisateur et sont de grandes consommatrices de bande passante réseau.

### Après 2000 : le client léger

Les applications client léger visent à éviter l'installation et les mises à jour des applications sur chaque poste utilisateur, qui occasionnent de forts coûts d'administration. Dans cette architecture apparue avec l'avènement du Web, toute la logique de traitement est en effet présente sur le serveur :
* La logique de traitement s'exécute pour une large part sur le serveur, occasionnant une charge réseau importante ;
* Une partie des traitements, notamment relevant de l'ergonomie, peut cependant s'exécuter sur le poste client, par exemple via le langage JavaScript. L'architecture client léger se caractérise en effet notamment par une moindre richesse des IHMs par rapport au client lourd, du fait notamment des limitations du langage HTML.
Le client léger est massivement utilisé aujourd'hui, beaucoup d'applications web fonctionnant sur ce modèle ; le client léger désigne alors le navigateur web.
C'est l'apparition de ce type d'architecture qui a engendré, par caricature, la dénomination de 'client lourd' pour les précédentes architectures.

### 2002 à aujourd'hui : les rich Internet application

Les Rich Internet application (RIA) sont apparues pour permettre une plus grande richesse dans les interfaces homme-machine (IHM) des applications web, afin notamment de pallier les insuffisances de HTML. Elles ouvrent des possibilités en termes d'interface homme-machine semblables à celles des applications traditionnelles en client-serveur. AJAX ou les technologies Adobe Flash sont des exemples de technologies RIA.
Le développement de HTML5 visait à pallier les insuffisances de HTML dans ce domaine.

### Aujourd'hui : le client riche

Le client riche permet de développer des applications traditionnelles type client lourd, ou des applications type client-serveur. Il propose :
* un framework de développement et des composants de base pour faciliter le travail des développeurs incluant notamment des composants IHM enrichis ;
* un environnement d'exécution à installer sur les postes clients, comprenant des composants de base sur lequel seront déployées les applications ; typiquement l'environnement d'exécution Java (JRE) pour les applications écrites en langage Java ;
* souvent une technologie de déploiement type Java Web Start permettant de simplifier et automatiser la mise à jour à distance des clients.
Les Rich Internet Applications sont fréquemment incluses dans la technologie client riche, car elles proposent elles aussi une ergonomie enrichie tout en restant déployées au niveau des serveurs, le navigateur web jouant alors le rôle d'environnement d'exécution.

## Client lourd contre client léger

Les clients lourds sont des logiciels destinés à être installés localement sur une machine en opposition aux clients légers qui s'exécutent par exemple dans un navigateur web, mais nécessitent obligatoirement un serveur. Un client riche tente de proposer le meilleur des deux mondes.
| | Client lourd | Client léger |
| Eléments requis pour l'exécution du client | Environnement d'exécution lié au système de la machine concernée | Application hôte type navigateur web, et connexion réseau haut débit |
| Exploitation des ressources locales de la machine hôte | Oui, meilleure exploitation du processeur, de la mémoire, de l'espace disque. Avec accès direct aux divers périphériques. | Très limitée, restreinte aux éléments supportés par le navigateur (multimédia) avec divers blocages inhérents aux mesures de sécurité |
| Fluidité d'exécution | Bonne en général | Tributaire du réseau (avec toutefois une meilleure réactivité avec l'exploitation de requêtes du type Ajax) |
| Modèle de travail | Possibilité de travailler en linéaire comme en parallèle (MDI). | En général, une seule tâche en linéaire |
| Type d'utilisation | Utilisation localisée de courte à longue durée | Utilisation nomade (accès de partout), à courte durée (limité par les aspects de session) |
| Ergonomie | Riche, widgets évolués | Limitée aux interfaces supportées par l'application hôte (HTML par exemple) |
| Coût d'administration | Déploiement et mises à jour unitaires par poste nécessaires | Gestion des postes clients fortement facilitée, mises à jour centralisées sur le serveur |
| Technologies | Plateformes client lourds (Microsoft CAB/VisualStudio, Borland Developer Studio, etc.) | Web 2.0, Ajax, XUL |
Des technologies comme Eclipse RCP, Java Web Start, ou NetBeans permettent de concilier ces deux approches, Eclipse RCP comme NetBeans permettant d'ailleurs toujours de produire du pur client lourd.

## Plateforme client riche

Une plateforme RCP fournit des briques logicielles de base pour construire une application, et le noyau exécutif pour la faire fonctionner.
Une plateforme client riche est composée à la base des éléments suivants :
* un noyau exécutif générique qui sert de glue (colle) pour assembler les briques et les faire interagir ;
* un framework évitant d'avoir à redévelopper tous les éléments d'une application : le développeur reprend les briques qui lui sont utiles et peut en créer ou en importer de nouvelles :
    par exemple Eclipse RCP et NetBeans RCP fonctionnent à base de plugins ;
* une interface utilisateur (avec par exemple des vues, des éditeurs, des assistants, etc) intégrant notamment un Environnement de développement.
On y ajoute également des fonctionnalités de mise à jour, de support d'aide…
Le framework et le noyau reposent tous deux sur le principe :
* d'un environnement d'exécution localisé sur chaque client, permettant à l'application de bénéficier des atouts du client lourd en termes de capacités de traitements et d'ergonomie IHM ;
* d'un environnement de déploiement localisé sur les serveurs, permettant au système de bénéficier des atouts du client léger en termes d'administration ;
* d'un stockage de données localisé au gré du développeur sur le poste client et/ou sur le(s) serveur(s), voire réparti.