Discussion :

[yphilogene]

Auriez-vous un exemple de risque de sécurité lié à une intelligence trop élevée du client?

A vrai dire, je ne suis pas sûr de comprendre ce qu'on entend par "intelligence du client", même si je concois que le client est amené à réaliser de plus en plus de traitements de son côté.

Quand vous dites que le service informatique veut avoir la maitrise de l'application, je pense qu'il s'agit essentiellement de la maitrise sur le déploiement et sur la sécurité d'accès aux données. Une fois ces deux aspects centralisés, je ne vois pas très bien où se situe les risques.



Je comprends mieux ce que tu entends par Peer To Peer Ludosoft. C'est vrai que le propre d'un serveur est d'écouter et de répondre aux demandes des clients. Le rafraichissement des données météorologiques sur un site par exemple passe par des requêtes régulières du client. Je ne connais pas très bien le protocole Peer To Peer, mais j'imagine qu'il y a un des postes qui déclenche une recherche (Emule par exemple) ou un téléchargement (Bittorrent) qui provoque des échanges en cascade entre les machines.

Pour moi, on se rapprocherait dans ce cas d'un mode de communication très équilibré entre le serveur et le client. Je ne suis même pas sûr qu'il soit encore exact de les nommer ainsi dans ce type de modèle.

Mais bon, ne poussons pas le sujet trop loin. Une RIA, ça reste une application web dans sa philosophie mais avec une ergonomie plus poussée. Je ne pense pas que l'objectif de JavaFX, Flex ou Silverlight soit de sortir de cette philosophie web.

[berceker united]

Auriez-vous un exemple de risque de sécurité lié à une intelligence trop élevée du client?

A vrai dire, je ne suis pas sûr de comprendre ce qu'on entend par "intelligence du client", même si je concois que le client est amené à réaliser de plus en plus de traitements de son côté.

Quand vous dites que le service informatique veut avoir la maitrise de l'application, je pense qu'il s'agit essentiellement de la maitrise sur le déploiement et sur la sécurité d'accès aux données. Une fois ces deux aspects centralisés, je ne vois pas très bien où se situe les risques.



Je comprends mieux ce que tu entends par Peer To Peer Ludosoft. C'est vrai que le propre d'un serveur est d'écouter et de répondre aux demandes des clients. Le rafraichissement des données météorologiques sur un site par exemple passe par des requêtes régulières du client. Je ne connais pas très bien le protocole Peer To Peer, mais j'imagine qu'il y a un des postes qui déclenche une recherche (Emule par exemple) ou un téléchargement (Bittorrent) qui provoque des échanges en cascade entre les machines.

Pour moi, on se rapprocherait dans ce cas d'un mode de communication très équilibré entre le serveur et le client. Je ne suis même pas sûr qu'il soit encore exact de les nommer ainsi dans ce type de modèle.

Mais bon, ne poussons pas le sujet trop loin. Une RIA, ça reste une application web dans sa philosophie mais avec une ergonomie plus poussée. Je ne pense pas que l'objectif de JavaFX, Flex ou Silverlight soit de sortir de cette philosophie web.

Exemple simpl, l'utilisation du javascript coté clien qui permet d'exploiter des failles du serveur.

[ludosoft]

Autre exemple : on peut faire subir n'importe quelle torture à un JAR lâchée sur le poste client (dump de mémoire, traficotage du bytcode, etc.). Idem pour JavaScript dont on peut intercepter le code.

Pour une sécurité optimale il faudrait partir du principe que l'on a aucun contrôle sur le poste client et du devenir du programme qui y est envoyé...

[berceker united]

Il est claire qu'il faut voir la sécurité des deux cotés. Si un pirate arrive à substitué l'adresse du serveur pour la mise à jour, vous ne savez pas ce que vous remontez.
Avec Ajax, il y a déjà des problèmes point de vue sacurité. Vous nez savez plus trop ce qu'il se passe en arrière plan. Sauf si vous controler le flux http.
Je pense que tant que ça reste au niveau d'un intranet ou extranet il y a pas trpo de souci à ce faire. Quand l'internet entier commence à s'y mettre, il y a un risque.
Actuellement, beaucoup de personne se laisse tenter par le web 2.0 qui à mon sens ne veut rien dire pour moi. Je pense qu'il y une monde qui est poussé par des clients mais c'est une vraie galère pour les développeurs.

[sleepy2002]

Bonjour,

J'ai travaillé sur des applications web écrites en Java pendant 3 ans. Depuis je suis sur des clients lourds mais connectés à un serveur. Je dois dire que c'est beaucoup plus simple de travailler sur du client lourd :
- Problèmatique de tests IHM : les frameworks de test web existent mais montrent vite leurs limites lorsqu'il y a du javascript à tout va (cf Ajax).
- Refactoring facile sur du code Java/Swing grâce aux IDE alors que côté web c'est l'enfer absolu.
- L'aspect debugging, configuration (argh ! les fichier XML d'hibernate, spring, struts, etc ...)

C'est hors sujet, mais au delà de la problèmatique du déploiement et du chargement de l'appli il y a aussi celle de la maintenance. Une équipe doit pouvoir rentrer rapidement de la code et mettre en oeuvre les évolutions demandées (bon, il faut que le code soit bien structuré). C'est pour celà que les applications stand alone, clientes dite lourdes sont loin d'être obsolètes.


En même temps, c'est un avis personnel, j'espère recevoir des contre-arguments .

[nicorama]

Je voudrais quand meme signaler que Ajax avec par exemple Prototype est très propre.
De plus vous pouvez mettre votre code dans un .js qui sera BEAUCOUP plus léger qu'une image - l'idée de page trop chargée ne tient pas.
Et en vous pouvez - devez ! - programmer des composants/templates/taglibs/cequevousvoulez qui évitent de reécire le code.

Evidemment la programmation web, ce n'est pas du C++ écrit avec une syntaxe unique. Ca demande beaucoup de compétences différentes et donc une séparation claires des tâche pour perenniser le code.
Il faut donc de l'organisation logique et architecturale plus complexe qu'avec un client lourd/intranet.

[Traroth2]

Salut à tous, côté Flash et DHTML, je trouve personnellement l'approche OpenLaszlo intéressante. On peut déployer une application en Flash ou DHTML, c'est au choix au moment de la compilation , même si le deploiement DHTML est encore une fonctionnalité bétâ. L'application Flash est compatible avec Flash dès la version 7. On peut faire plein de trucs, faire fonctionner l'appli avec des jsp, du PHP, en fait avec tout ce qui peut retourner du XML à partir d'un base de données.
Pour moi, les applications clients légers ont donc un bel avenir devant elles, surtout avec les vitesses de connexion qui augmentent pas mal depuis qqs années.

Oui, OpenLazslo, c'est un truc qui a un potentiel énorme. L'idée de développer dans un langage spécifique, puis de générer le code derrière en Flash, Ajax ou autre chose (on pourrait imaginer des générateur Silverlight ou JavaFX, d'ailleurs), je trouve ça super. Ca se rapproche un peu des principes MDA / MDD.

[Traroth2]

Je trouve que sur le marché du le client riche Adobe à un peut merdé avec Flash. En effet, Flash embarque déjà un sérieux baguage. Je comprend pas pourquoi ils se sont pas axé dessus pour l'ouvrir un peut plus ou la création d'une framework.
Pour Ajax, je pense qu'il y a eu une sorte d'erection entre fin 2006, début 2007. Après, il y a eu une sorte de feed-back plutôt négatif car beaucoup ont trouvé des limites à cette technologie. Certe, des grosses société y ont fait de sacré application avec techno. Google sans le nommé. Mais beaucoup s'y sont cassé les dents et ont fait marche arrière très rapidement.
Il y a une voie qui souvre qui est le Web Service. Le moteur est sur le serveur d'application et l'application graphique reste sur le poste client.

Ca, c'est clair. Le précédent projet sur lequel je bossais (scroon.com) devait être développé en tout Ajax, et c'est rapidement devenu un enfer, même en utilisant Prototype (quand le designer a besoin d'utiliser les id des éléments HTML pour ses CSS, et que vous en avez besoin pour vos scripts, vous faites quoi ?)

[Traroth2]

Auriez-vous un exemple de risque de sécurité lié à une intelligence trop élevée du client?

A vrai dire, je ne suis pas sûr de comprendre ce qu'on entend par "intelligence du client", même si je concois que le client est amené à réaliser de plus en plus de traitements de son côté.

Quand vous dites que le service informatique veut avoir la maitrise de l'application, je pense qu'il s'agit essentiellement de la maitrise sur le déploiement et sur la sécurité d'accès aux données. Une fois ces deux aspects centralisés, je ne vois pas très bien où se situe les risques.



Je comprends mieux ce que tu entends par Peer To Peer Ludosoft. C'est vrai que le propre d'un serveur est d'écouter et de répondre aux demandes des clients. Le rafraichissement des données météorologiques sur un site par exemple passe par des requêtes régulières du client. Je ne connais pas très bien le protocole Peer To Peer, mais j'imagine qu'il y a un des postes qui déclenche une recherche (Emule par exemple) ou un téléchargement (Bittorrent) qui provoque des échanges en cascade entre les machines.

Pour moi, on se rapprocherait dans ce cas d'un mode de communication très équilibré entre le serveur et le client. Je ne suis même pas sûr qu'il soit encore exact de les nommer ainsi dans ce type de modèle.

Mais bon, ne poussons pas le sujet trop loin. Une RIA, ça reste une application web dans sa philosophie mais avec une ergonomie plus poussée. Je ne pense pas que l'objectif de JavaFX, Flex ou Silverlight soit de sortir de cette philosophie web.

Dans un contexte client-serveur, tous les contrôles de sécurité doivent être fait au niveau serveur, parce qu'on ne peut pas permettre au client d'accéder aux données sans être bien sûr que la procédure de contrôle a bie eu lieu. Les données qui proviennent du client, on ne sait pas par quelle moulinette elles peuvent être passées. Après, dans un but de réactivité, on peut faire le controle *aussi* coté client, et là on entre dans un des problèmes actuels du RIA : les traitements qu'on fait en double, au niveau client *et* au niveau serveur.

[_Mac_]

Mais bon, ne poussons pas le sujet trop loin. Une RIA, ça reste une application web dans sa philosophie mais avec une ergonomie plus poussée. Je ne pense pas que l'objectif de JavaFX, Flex ou Silverlight soit de sortir de cette philosophie web.

Je ne suis pas tout à fait d'accord : avec le client riche, on entend répondre à la problématique du mode déconnecté avec sauvegarde locale puis synchronisation : ce n'est tout simplement pas possible avec une application Web sans plug-in ou extension. Tout ne tourne pas qu'autour de l'ergonomie, même si c'est une composante importante du problème.

[yphilogene]

Je ne suis pas tout à fait d'accord : avec le client riche, on entend répondre à la problématique du mode déconnecté avec sauvegarde locale puis synchronisation : ce n'est tout simplement pas possible avec une application Web sans plug-in ou extension. Tout ne tourne pas qu'autour de l'ergonomie, même si c'est une composante importante du problème.

D'accord. J'ai voulu simplifier un peu la chose.

Je vois bien ce qu'apporte le client riche par rapport au client léger, notamment sur la problématique du mode déconnecté. Donc, un client léger ne peut pas faire certaines opérations et le client riche entend répondre à ces manques.

Mais quelle est la différence fondamentale entre un client lourd (pouvant communiquer avec un serveur) et une RIA? Pour moi, elle est uniquement philosophique .

Il existe des applications proposant de la synchronisation de contenus client<-->serveur dans le monde des clients lourds depuis longtemps (Lotus Notes par exemple). Imaginons qu'on développe une RIA (donc avec des technologies Adobe AIR, JavaFX ou autre) qui propose un mode déconnecté, de la synchronisation de contenu, une ergonomie type client lourd et encore plein d'autres choses. Dans ce cas, pourquoi l'appellerait-on RIA au lieu de client lourd? A cause des technologies utilisées derrière?

[bassim]

Dans ce cas, pourquoi l'appellerait-on RIA au lieu de client lourd? A cause des technologies utilisées derrière?

parceque déja une application client lourd à la différence d'une RIA ne s'execute pas sur un navigateur;
et une application lourd doit gérer elle même les communications réseaux sans forcément passer par du Http

[yphilogene]

parceque déja une application client lourd à la différence d'une RIA ne s'execute pas sur un navigateur;

Oui, c'est tout à fait vrai. C'est moi qui me suis mal exprimé.

RIA: client riche s'executant dans un navigateur.
RDA: client riche s'executant hors navigateur.

Je reformule donc ma question: quelle est la différence entre un RDA et un client lourd? Est-ce les technologies utilisées derrière?

et une application lourd doit gérer elle même les communications réseaux sans forcément passer par du Http

Tu veux dire que pour les RIA c'est le navigateur qui gère les communications (HTTP, FTP...). Mais pour les RDA, j'imagine que le choix du protocole est libre, non?

Qui a déjà développé une RDA? Quelles différences avez-vous notées par rapport à un développement de client lourd?

[yphilogene]

RIA (Rich Internet Application): client riche basé sur un navigateur.
RDA (Rich Desktop Application): client riche basé sur un moteur (Adobe AIR par exemple).

Tout le monde est ok avec ça?

Partant de là, je me pose la question suivante: RIA ou RDA?

1) Au niveau du déploiement et des mises à jour:

RIA:
- Mise à jour de l'application directement côté serveur, aucun déploiement à effectuer côté client.
- Mise à jour du navigateur potentiellement automatique (comme cela se fait par exemple avec Firefox).

RDA:
- A moins que l'application ne s'utilise comme une applet Java, je pense qu'il est juste de dire qu'il faille updater l'application partout côté client.
- Mise à jour du moteur potentiellement automatique (comme avec la JRE).

Je dirais avantage à la RIA, mais c'est discutable. La mise à jour de la JRE et le déploiement façon applet me plait bien moi...

2) Au niveau de l'utilisation

RIA:
- Le problème avec le navigateur... c'est qu'il est un navigateur, avec ses boutons Back, Refresh,... indispensables pour surfer sur Internet, mais à banir lors de l'utilisation d'une RIA.

RDA:
- Aucun problème, c'est comme un client lourd, avec des fonctionnalités totalement dédiées à la RDA.

Il semble indiscutable que la RDA domine la RIA sur ce point.

3) Au niveau du développement

Est-ce qu'une RIA et une RDA se développent de la même façon (grosso modo)? Autrement dit, la phase de design pour une RDA se fait-elle aussi rapidement que pour une RIA?

[Traroth2]

3) Au niveau du développement

Est-ce qu'une RIA et une RDA se développent de la même façon (grosso modo)? Autrement dit, la phase de design pour une RDA se fait-elle aussi rapidement que pour une RIA?

Ben pour l'instant, la seule techno permettant de faire à la fois du RIA et du RDA, c'est flex/AIR, et ça se passe exactement de la même manière. On a fait une version RDA (AIR) avec notre client RIA (Flex) en une heure, à peu près.
Pour l'instant, sinon, il y a les technos RIA d'un coté (Silverlight, JavaFX) et les technos RDA de l'autre (XUL, EclipseRCP). Bon, je connais pas vraiment le monde .Net, donc je ne peux pas trop m'exprimer sur l'offre .Net en matière de RDA ni sur le passage d'une application .Net à une application Silverlight. D'ailleurs, si quelqu'un a une idée sur la question...

[yphilogene]

Ben pour l'instant, la seule techno permettant de faire à la fois du RIA et du RDA, c'est flex/AIR, et ça se passe exactement de la même manière. On a fait une version RDA (AIR) avec notre client RIA (Flex) en une heure, à peu près.

Qu'est-ce qui change en fait? Vous vous êtes contenté d'extirper l'application du navigateur pour la mettre dans un viewer fait maison?

[nicorama]

Ca, c'est clair. Le précédent projet sur lequel je bossais (scroon.com) devait être développé en tout Ajax, et c'est rapidement devenu un enfer, même en utilisant Prototype (quand le designer a besoin d'utiliser les id des éléments HTML pour ses CSS, et que vous en avez besoin pour vos scripts, vous faites quoi ?)

Je ne vois pas le soucis.
De plus pour moi on ne développe pas en Ajax, ca veut rien dire. C'est comme si je voulais développer en HTTP.
Ce qui compte, c'est la programmation serveur, et le degrès d'intervention de Javascript côté client.
Pour moi Ajax n'est qu'un moyen parmi d'autres d'amener des datas sur l'écran.

[hackingcode]

Bonjour à tous,

Si j'ai bien compris ce que tout le monde a écrit dans les précédents post, ce qu'il faudrait en fait c'est une technologie qui fonctionne sur tous les postes clients (mac, windows, linux).

Naturellement celle-ci doit permettre la réalisation d'applications RIA et RDA et mobile performantes avec un seul code (XML de présentation, style et code) pour tous les systèmes et dont le téléchargement serait pris en compte soit directement par le navigateur soit par un plug-in intégré au navigateur soit directement utilisable par un interpréteur (navigateur XML ?) installé en local sur le poste de travail.

Naturellement, les applications interprétées seraient téléchargées dynamiquement à partir de serveurs web de tous types (IIS, J2EE,...) le tout via des requêtes HTTP standards post et/ou get.

En outre, les données pourraient être accédées via web services, rest ou un simple process distant.

ais-je bien résumé les besoins ?

[yphilogene]

Bonjour à tous,

Si j'ai bien compris ce que tout le monde a écrit dans les précédents post, ce qu'il faudrait en fait c'est une technologie qui fonctionne sur tous les postes clients (mac, windows, linux).

Naturellement celle-ci doit permettre la réalisation d'applications RIA et RDA et mobile performantes avec un seul code (XML de présentation, style et code) pour tous les systèmes et dont le téléchargement serait pris en compte soit directement par le navigateur soit par un plug-in intégré au navigateur soit directement utilisable par un interpréteur (navigateur XML ?) installé en local sur le poste de travail.

Naturellement, les applications interprétées seraient téléchargées dynamiquement à partir de serveurs web de tous types (IIS, J2EE,...) le tout via des requêtes HTTP standards post et/ou get.

En outre, les données pourraient être accédées via web services, rest ou un simple process distant.

ais-je bien résumé les besoins ?

Pour moi, c'est un excellent résumé. Pour ce qui est de l'interpréteur, je vois plutôt ça comme une sorte de viewer fait maison et spécifique à l'application. L'idée est de se débarasser des inconvénients du navigateur. Mozilla Prism est un bon exemple de départ. Il permet d'exécuter une application web (par exemple GMail, Facebook, Meebo, Deezer,...) dans une fenêtre simple.

Alors, pour toi, c'est quoi la technologie actuelle répondant à cet ensemble de besoins?

[berceker united]

Pour moi, c'est un excellent résumé. Pour ce qui est de l'interpréteur, je vois plutôt ça comme une sorte de viewer fait maison et spécifique à l'application. L'idée est de se débarasser des inconvénients du navigateur. Mozilla Prism est un bon exemple de départ. Il permet d'exécuter une application web (par exemple GMail, Facebook, Meebo, Deezer,...) dans une fenêtre simple.

Alors, pour toi, c'est quoi la technologie actuelle répondant à cet ensemble de besoins?

Excellent ce Mozilla Prism. Je pense que c'est une solution à pas mal de problème.