Discussion :

[kervoaz]

Bonjour,

Mon experience perso:
Je travaille sous Oracle Forms(AGL pour base oracle) sur une appli d'environ 350 ecrans et quelques 5000 users. Cette appli etait jusqu'à peu en client-serveur. Les montées de version etaient plus que penibles(modifications à livrer sur 5000 postes). Avec les nouvelles versions d'Oracle et moyennant une moulinette sur les ecrans, l'appli se transforme en "client web", une applet en fait. Et bien je peux vous assurer que les boutons precedent,suivant,F1 ,fermer la fenetre du navigateur deviennent un cauchemar.:
Le user qui trouvait trop long le traitement de sa compta(1 000 000 de lignes) ferme sa fenetre->un lock. Le meme gars relance le traitement parce qu'il n'y aucune raison que ca ne marche pas->c'est fini on appelle la hot line. Pour peu que la table lockée soit souvent accedée en ecriture, tous les users sont bloqués et la hot line explose. Ici,c'est l'exemple d'un user qui fait une boulette mais ca peut etre une coupure reso, le browser qui plante...
Je ne parle pas des fonctionalites qui n'existent plus (le survol des items à la souris)..
Enfin le plus important est à mon avis la quasi obligation de changer le serveur pour supporter les traitements(qui sont alors deportés evidemment sur le serveur).

Bref je ne suis pas convaincu de la mode "client leger" meme si ca fait marcher le commerce..

Pour me conforter dans cette idée, j'ai egalement travailler sur une appli java/struts/javascript. N'etant pas expert sur cette techno, la gestion des objets en session, le design des pages et l'integration de javascript m'a paru tres lourde. Le simple fait d'enchainer des listes box dependantes les unes des autres sans rechargement de la page(Ajax) est une vrai galere. La page jsp devient un merdier infame bourrée de js,tag jsp,html, css..

Pour conclure (ouf), meme si le Web 2.0 est dans la bouche d'un tas de de mec en cravate et qu'il soit LA SOLUTION a tous les problemes, je ne suis pas sur que l'utilsateur final en soit convaincu.

[mezoo]

Les "nouvelles" techno comme Ajax et une bonne manipulation des feuilles de style font qu'au niveau ergonomie l'utilisateur est largement satisfait. Pour le reste c'est plutot une question de performance et de préférence. D'expérience la plupart des applis réalisé passe par le web et des frameworks.

A +

[gorgonite]

Un autre piste mais qui est encore peu exploité est XUL. Ca permet de concevoir des applications dans Firefox (qui existe pour Windows ou Linux).
Un exemple est visible :
http://www.faser.net/mab/chrome/content/mab.xul

+1
selon moi, XUL/XPCom représente l'avenir du client léger "propre", ie avec des standards ouverts... les possibilités sont beaucoup plus intéressantes que les solutions java, on peut se servir d'une philosphie ajax, pour accélerer les opérations, etc.

en revanche, le temps d'apprentissage est un peu long, et la plate-forme de développement nécessite une compilation complète de mozilla, avec des risques de problèmes de dépendances (PyXPCom par exemple)

[etranger]

a propos quel technique est utilisée ICI ?

[gorgonite]

a propos quel technique est utilisée ICI ?

ben je dirais asp.net, avec pas mal de jscript compatible MSIE uniquement afin de pouvoir espionner au mieux ton système (l'objet wsh si je me souviens bien)

[harobed]

Bonjour,

Mon experience perso:
Je travaille sous Oracle Forms(AGL pour base oracle) sur une appli d'environ 350 ecrans et quelques 5000 users. Cette appli etait jusqu'à peu en client-serveur. Les montées de version etaient plus que penibles(modifications à livrer sur 5000 postes). Avec les nouvelles versions d'Oracle et moyennant une moulinette sur les ecrans, l'appli se transforme en "client web", une applet en fait. Et bien je peux vous assurer que les boutons precedent,suivant,F1 ,fermer la fenetre du navigateur deviennent un cauchemar.:
Le user qui trouvait trop long le traitement de sa compta(1 000 000 de lignes) ferme sa fenetre->un lock. Le meme gars relance le traitement parce qu'il n'y aucune raison que ca ne marche pas->c'est fini on appelle la hot line. Pour peu que la table lockée soit souvent accedée en ecriture, tous les users sont bloqués et la hot line explose. Ici,c'est l'exemple d'un user qui fait une boulette mais ca peut etre une coupure reso, le browser qui plante...
Je ne parle pas des fonctionalites qui n'existent plus (le survol des items à la souris)..
Enfin le plus important est à mon avis la quasi obligation de changer le serveur pour supporter les traitements(qui sont alors deportés evidemment sur le serveur).

Bref je ne suis pas convaincu de la mode "client leger" meme si ca fait marcher le commerce..

Pour me conforter dans cette idée, j'ai egalement travailler sur une appli java/struts/javascript. N'etant pas expert sur cette techno, la gestion des objets en session, le design des pages et l'integration de javascript m'a paru tres lourde. Le simple fait d'enchainer des listes box dependantes les unes des autres sans rechargement de la page(Ajax) est une vrai galere. La page jsp devient un merdier infame bourrée de js,tag jsp,html, css..

Pour conclure (ouf), meme si le Web 2.0 est dans la bouche d'un tas de de mec en cravate et qu'il soit LA SOLUTION a tous les problemes, je ne suis pas sur que l'utilsateur final en soit convaincu.

100% d'accord avec toi.

Par contre, comme il est dis un peu plus haut, la solution XUL me paraît un bon choix à l'avenir.

[deneb]

Ce n'est pas le navigateur qui est utilisé en tant que client, mais ce qu'il contient. Si le contenu n'est pas trop convivial, et fonctionnel, g ne crois pas que la prise en main sera aussi rapide que cela.
D'autre part AJAX commence à rendre les clients Web vraiment riche

Tous ces avantages du client Web que vous avez donnés sont possibles à obtenir avec une architecture client-serveur en utilisant un deploiement Citrix/Terminal server, avec néanmoins comme principal inconvénient le coût des licences c'est tout.
Je suis quand même surpris que personne n'ait évoqué celà depuis!

Et pourquoi passer par cette usine à gaz de Citrix ?
Une application Java déployée avec Webstart combine le meilleur des deux mondes (C/S et Web).

• Déploiement et mises à jour automatiques
• Pas plus de pb de compatibilité qu'en Web.
• Développement simplifié du fait qu'il y moins de technos mélangées (Java de bout en bout).
• Ressources serveurs très largement optimisées
• Bande passante très réduite.
• Ergonomie incomparable..

Que voulez vous de plus ?

C'est d'ailleurs pour toutes ces raisons que le Web 2.0 a tant de succes.
Ca n'est pourtant qu'une vaste supercherie commercialo/technophile qui essaye de batir de vraie application (au sens ou les traitements s'executent sur le client) tout en n'osant pas rompre avec le navigateur.

[kisitomomotene]

Et pourquoi passer par cette usine à gaz de Citrix ?
Une application Java déployée avec Webstart combine le meilleur des deux mondes (C/S et Web).

La solution java web start est une solution de deploiement d'un client lourd avec les problèmes liés au client lourd. Je vais vous faire un témoignage. J'avais dans le cadre du développement d'une application utilisé dans un premier temps la technologie java Web start. Une fois l'application téléchargées sur les postes client, sur certain poste client l'application n'arrivait pas à se connecter sur le serveur d'application ( certainement à cause de l'architecture et de la sécurité du réseau sous jacent) malgré l'ouverture du port jndi sur mon serveur. Je n'avais pas autorité à résoudre les problèmes réseaux, et cela devait être compliqué de diagnostiquer et de faire résoudre le problème par les administrateurs réseau.
Sur d'autre poste l'application ramait véritablement(c'est un euphemisme), parceque ces postes n'avaient pas de forte capacité ( et vraiment swing est trop lourd).

Alors j'ai décidé d'utiliser un seveur très puissant sur lequel les utilisatuers vont s'y connecter par terminal server. Pas de déploiement à faire sur les postes clients (tous ont Win XP), je surveille toutes l'activité de mon appli sur un seul poste (mon serveur) imaginez un peu si vous devez surveillez une application déployé sur chaque poste client! sur un poste X c'est peu être un virus , sur un poste Y un autre problème etc etc..
Comme tous les utilisateurs ne sont pas actifs en même temps, l'application devient alors un vrais turbo pour le peu qui sont connectés car ils ont ttes les ressources du puissants serveur à eux tous seuls.

C'est vrai un inconvénient de TS/Citrix est la grande consomation des ressource du serveur par rapport aux solutions basées sur le web,, ce qui fait que pour avoir une solution performante à grde echelle il faut acquérir des serveurs 2 à 4 fois plus puissants que des serveurs pour le web, et payer des licences d'utilisations pour chaque utilisateurs, ce qui finalement coûte très chère.

[deneb]

La solution java web start est une solution de deploiement d'un client lourd avec les problèmes liés au client lourd. Je vais vous faire un témoignage. J'avais dans le cadre du développement d'une application utilisé dans un premier temps la technologie java Web start. Une fois l'application téléchargées sur les postes client, sur certain poste client l'application n'arrivait pas à se connecter sur le serveur d'application ( certainement à cause de l'architecture et de la sécurité du réseau sous jacent) malgré l'ouverture du port jndi sur mon serveur. Je n'avais pas autorité à résoudre les problèmes réseaux, et cela devait être compliqué de diagnostiquer et de faire résoudre le problème par les administrateurs réseau.

utiliser un port spécifique JNDI est déjà une erreur.
Il faut se limiter aux port 80 et 443 qui sont ouverts partout.
Ensuite il convient dans l'ouverture des socket de tenir compte de la présence ou non d'un proxy...après tout roule

Sur d'autre poste l'application ramait véritablement(c'est un euphemisme), parceque ces postes n'avaient pas de forte capacité ( et vraiment swing est trop lourd).

Swing est lourd quand les appli sont mal programmées.
Sinon il existe aussi SWT (c'est ce que nous utilisons).

Alors j'ai décidé d'utiliser un seveur très puissant sur lequel les utilisatuers vont s'y connecter par terminal server. Pas de déploiement à faire sur les postes clients (tous ont Win XP), je surveille toutes l'activité de mon appli sur un seul poste (mon serveur) imaginez un peu si vous devez surveillez une application déployé sur chaque poste client! sur un poste X c'est peu être un virus , sur un poste Y un autre problème etc etc..
Comme tous les utilisateurs ne sont pas actifs en même temps, l'application devient alors un vrais turbo pour le peu qui sont connectés car ils ont ttes les ressources du puissants serveur à eux tous seuls.

C'est vrai un inconvénient de TS/Citrix est la grande consomation des ressource du serveur par rapport aux solutions basées sur le web,, ce qui fait que pour avoir une solution performante à grde echelle il faut acquérir des serveurs 2 à 4 fois plus puissants que des serveurs pour le web, et payer des licences d'utilisations pour chaque utilisateurs, ce qui finalement coûte très chère.

Très très cher...

[kisitomomotene]

utiliser un port spécifique JNDI est déjà une erreur.
Il faut se limiter aux port 80 et 443 qui sont ouverts partout.
Ensuite il convient dans l'ouverture des socket de tenir compte de la présence ou non d'un proxy...après tout roule

On utilise un port donné lorsque le service qu'on veut utiliser est mappé sur ce port. Ce n'est pas tous les services, qui utilise les ports http/https. Particulièrement en client/serveur, il y a beaucoup de protocoles proprietaire qui n'utilisent même pas de port fixe (IIOP, DCom par exemple n'utilise pas de port fixe) et en plus ceux qui en utilisent, ne se servent pas tjrs d'un tunnel http/https pour passer des firewall.
Quand je parle d'utiliser un port JNDI, c'est obligatoire si on veut se connecter à un serveur d'application j2EE.

[deneb]

On utilise un port donné lorsque le service qu'on veut utiliser est mappé sur ce port. Ce n'est pas tous les services, qui utilise les ports http/https. Particulièrement en client/serveur, il y a beaucoup de protocoles proprietaire qui n'utilisent même pas de port fixe (IIOP, DCom par exemple n'utilise pas de port fixe) et en plus ceux qui en utilisent, ne se servent pas tjrs d'un tunnel http/https pour passer des firewall.
Quand je parle d'utiliser un port JNDI, c'est obligatoire si on veut se connecter à un serveur d'application j2EE.

Oui je sais...ce que je veux dire c'est que si on veut faire des applications clients serveur réellement "deployables"...il ne faut pas utiliser de tels protocoles.
D'ailleurs franchement IIOP c'est la pire des solution pour faire des applications C/S. (tout comme J2EE, mais c'est un autre débat ).

Une bonne socket TCP sur un port ouvert (80 ou 443) et on peut faire passer tout ce qu'on veut.
Ca fait 3 ans qu'on fait des applications comme ça avec mon équipe et je garantie que ça marche à merveille.

[siplusplus]

Bonjour,

Il faudrait peut-être penser à mettre cette discussion comme "résolue"
ça fait plus d'un an que l'auteur de la question n'a plus écrit lol .

[LauBelette]

Je ne pense pas qu'il faut mettre résolu car ce n'est pas résolu pour moi. Je viens de lire tout le post et je suis encore plus indecit

Je dois également faire une application de gestion qui va devoir être installée sur plusieurs postes (pas énormément) dans des bâtiments différents et éloignés. Pour des questions simplement d'installation, je pense que je vais m'orienter vers une solution web (PHP/MySQL) car si je dois à chaque fois me déplacer pour débuger, ça va me coûter cher en temps et en diesel

[siplusplus]

Pffiou, après 2 ans (aur)ont-ils encore besoin d'une appli ?
Si les sites sont éloignés les uns des autres, il vaut mieux aller dans ce sens.
Mais ce n'est qu'une partie des spécifications.
Analyse, il n'y a que ça de vrai .
Et puis la dépense carburant par rapport au salaire peut devenir un détail si c'est
tout bénéfice. Si c'est un travail à l'heure, au forfait, on est indépendant, ...
Ca en fait des facteurs ...

[kromartien]

Au décathlon de Parly 2, il y a avait une apllication client serveur visiblement base sur PHP, puisque les clients étaient le navigateur web internet explorer ou son pendant Mozilla Firefox, je ne sais plus. Toujours est-il qu'il servait à la gestion des stocks je crois (consultation) mais je ne sais pas jusqu'à quel niveau était poussé le niveau de fonctionnalités (prise de commande, gestion des tâches, des références, etc ... ).