Pourquoi un "Rich Client" plutot qu'une "RIA" (Rich Internet Application) ?

 

En préembule je dois reconnaitre qu'il est vrai que les outils dédiés aux RIA s'ammeliorent très rapidement, Ajax, Flex, Flash, Silverlight, ect... mais car il y a un "Mais" Je vais essayer d'enumerer ici les raisons pour lesquelles je prefere quand meme developper une application de type Client Riche plutot qu'une Interface web pour créér un logiciel, j'argumenterai au fil du temps pour completer cet article.

Pour :

Le poste client est de plus en plus puissant.

il n'est pas rare de trouver des "dual core" avec des cartes graphiques incroyables, reserver l'usage de ces machines a l'utilisation d'un navigateur web pour qu'il ne s'occupe que de la couche UI d'une application, c'est vraiment sous utiliser un systeme qui peut soulager d'une manière spéctaculaire un serveur.

Une experience utilisateur sans limite.

Meme si avec des technologies comme Ajax, on peut voir arriver de l'autocompletion ou du drag n drop, ça ne gere pas encore les frozen columns dans les datagridview, et très mal le paging continu (sauf google reader ;) ).

Avec une application il est assez aisé de contextualiser l'information.

la vitesse d'affichage ne depends pas d'un serveur web.

Gestion possible d'un dual screen voir plus.

Possibilité de passer en mode deconnecté.

Un accès au systeme d'information local aisé.

J'ai besoin d'acceder aux documents presents sur le poste hote, je n'ai pas besoin de l'envoyer au serveur web pour le traiter

Un deployement sélectif.

Souvent on entends dire, oui avec une RIA, je mets tous mes utilsateurs a jour d'un seul coup, certe. Mais on ne peut pas mettre son application a jour pour un groupe d'utilisateur precis sauf à leur indiquer une nouvelle adresse internet, avec Clickonce ceci est tout a fait possible.

Impression des documents.

Le poste client a toute les capacité pour produire une impression d'un document, pas besoin de faire un rendu html ou l'impression est très mal gérée, certe il est possible de demander a un serveur de produire un document word ou pdf et de le telecharger pour l'imprimer mais la solicitation du serveur est augmenté ainsi que la bande passante disponible.

Utilisation des ressources locales.

Possibilité d'envoyer un document par fax, en composant automatiquemnet le numéro du correspondant sans avoir a le saisir une nieme fois.

Possibilité de crawler de l'information sur internet.

Possibilité d'acceder a un CTI dans l'application, ouvir la fiche du client qui appelle au téléphone.

Peer to Peer.

Possibilité de faire communiquer les applications entre elles sans passer par un serveur central.

Un environnement de travail stable et sans surprise.

Application deployée est complement controlée par l'editeur, il n'y a pas de plugin qui peuvent venir poluer l'information,

Avec un navigateur web on ne controle pas la version installée, les plugins installés, l'avenir , est-ce qu'un nouvelle regle de securité ne va pas bloquer telle ou telle fonctionnalité de l'application.

On ne travaille que pour une version, pas besoin d'etre "Crossbrowsing". Meme si l'on doit prendre en compte les spécificités des frameworks installés sur les postes hotes.

Contre:

Securité lors du deployement.

j'ai été confronté recement au deployement d'une application via clickonce sur un poste client, celui-ci avait anti-virus, anti-spyware et firewall et etait derrière un proxy web, et je dois dire que ça n'a pas été simple, en effet l'antivirus ou le proxy interdisait les urls contenant un .exe, du coup impossible de passer directement le bootstrapper (setup.exe) j'ai donc fait un zip, le download a réussi, mais le poste client n'avait pas le framework 2.0 installé et le bootstrapper a lancé le téléchargement , mais l'url contient elle meme un .exe, après quelques dizaines de minutes l'opération d'installation a reussi mais dans la douleur.

Gestion des ressources locales

Il faut s'assurer qu'il reste de la place sur le disque dur.

Il faut avoir suffisement de mémoire.

il faut s'assurer qu'on a le droit de sauvegarder des settings dans une répertoire.

il faut savoir si l'utilisateur est administrateur ou pas de la machine.

Gestion de la securité de l'application

Meme si cette problèmatique existe d'une certaine manière dans une application web (SQL Injection par exemple) elle est démultipliée dans une applicatoin riche. Possibilité de detourner l'usage des assemblies qui composent l'application, Injection de code, version inférieure à celle attendue.

 

Au passage j'utilise Windows Live Writer qui est lui meme un client riche pour publier des articles sur un blog ;)

Aucun commentaire: