Discussion :

[silvermoon]

c un débat qui peut durer très longtemps.

voila je travail actuellement sur un logiciel en client/serveur.
le problème qui se pose c'est l'installation sur les postes clients.

j ai commencé à développer une version web ( html+php+javascript) de cette application parce que cela permet de n'installer que sur un serveur donc cela plait aux services informatiques des clients, cela diminue le cout de la maintenance, le problème c'est qu'il n'est pas possible de faire les mêmes fonctionnalité qu'un logiciel client/serveur donc l'utilisateur final ne sera pas très content.

plus j avance dans mon projet web plus je me rend compte que le web c franchement limiter.

des sociétés éditeurs de logiciels ont palié à sa en développent des applications java qu'on peut charger à partir d'une page intranet ou internet ce qui permet de ne s'occuper que du serveur.
donc on accès via intranet à ces applications et on travaille en client/serveur donc on a tout les avantages et pas les inconvénients.

[silvermoon]

voici un exemple d'un des pages de mon appli en client serveur :

- 10 onglets.
- +100 champs.
- possibilité de recherche multi critères ou de séléction.
- il y a environ une cinquantaine de traitement derrière lorsqu on valide les informations.
cela fonctionne très bien en C/S

mais en web (html + php + javascript) c virtuellement du domaine du rêve ou alors qu'on donne une solution.

est ce que vous pensez que c réalisable de refaire un application C/S en web (html + php + javascript ) ?

[Petrus]

Salut,

Saches que le modèle d'application Internet s'appelle une application client serveur universel, selon les classifications officielles des architectures.

Pourtant si tu utilises la technologie Java avec des JSP/Servlets, etc.., tu peux faire des applications trés avancées. Si tu ne veux pas t'embéter avec les installations et la maintenance coté client, faire une application client serveur universel est idéal, comme tu le soulignes.

Quelles considérations techniques te font penser que tu devrais changer d'architecture ?

- 10 onglets.
- +100 champs.
- possibilité de recherche multi critères ou de séléction.
- il y a environ une cinquantaine de traitement derrière lorsqu on valide les informations.
cela fonctionne très bien en C/S

Il est certain qu'une applciation web nécessite une application particulière pour l'interfacage et l'agencement des fonctionnalités, mais la gestion de 100 ene de champs est qqch de classique, pour les traitemens, si tu utilisese des servlets , il n'y aura aucun probleme.

Bonne chance

[RDM]

pour des applica&tions CLient/Serveur Web (dite de 3eme génération) regardait XMLRAD (http://xmlrad.com)
c'est un outil fait pour cela

[silvermoon]

ok merci,

certe le jsp est très bien mais les serveur d'appli coute cher donc je le fais en php.

[neo.51]

Tu as combien de clients qui vont se servir de ton applis : c'est une applis de gestion interne d'une entreprise.

[silvermoon]

en faite , dans le web il est très dur de faire des fonctions comme faire un traitement de texte intégrés avec des règles et tout les autres trucs comme en client/serveur.

il n'est pas évident de faire des fonctions permettant de déplacer simplement une colonne dans un tableau html, par exemple : je veux mettre la colonne 5 avant la colonne 1 c très facile en client/serveur.

et il y en a bien d autre, franchement le web c bien joli mais c beaucoup plus lourd pour les clients finaux , nombre de cliques supérieur au client serveur , manip plus lourde et j en passe, je suis pas le seul le dire, tout les informaticiens que je rencontre dans les services informatiques de société cliente me dise que le web c bien pour eux parce que coté maintenance c le top juste le serveur à installer et a maintenir mais coté utilisation pour les clients finaux c franchement pas terrible voir très lourd.

[neo.51]

Tout dépend de ce que doit offrir ton service

[silvermoon]

c une appli interne

bon, voila c simple c une application pour la maintenance qui doit gérer des équipements, des stocks, des achats, des commandes, des contrats, des bons de travaux, des historiques, ... en le faisant en web on peut tourner à plus de 100 personnes connecter simultanéments sur la base de données, sur certaines pages il peut y avoir plus de 100 requetes donc 100 * 100 = 10 000 c déjà pas mal, pour une base, et il faut que cela aussi rapide que du client serveur et aussi souple niveau utilisations.

je pense que c pour sa que le web a énormément de mal à percer en entreprise.

j ai refais une appli C/S en web, je vais 10 fois plus vite avec le C/S que le web, web ( temps de rechergement de la page à chaque requete ) obligation d'utiliser la souris et le clavier donc perte de temps, avec les solutions C/S , nos clients n'utilises que le clavier, ils vont beaucoup plus vite.

il n y a que le service informatique qui est content car il y a juste le serveur à maintenir.

[Rami]

Je ne remet absolument pas en question ton analyse, mais je pense qu'on ne peut pas, en effet, transposer une appli C/S -> web comme ca.

Il faut vraiment refaire une analyse du design en prenant en compte les contraintes liées au appli web.

D'où: pour les utilisateur finaux, se retrouver avec une nouvelle interface -> perte des acquis s'ils sont déja habitués à une certaine interface.

D'où ma conclusion:
dés le départ savoir ce que l'on veut faire: C/S ou web suite à une bonne analyse.
créer un design adapté.

La remise en cause des choix de départ est toujours couteuse pour le développement et pour le client.

[silvermoon]

je suis tout à fais d'accord avec toi Rami, seulement je ne suis pas le seul à décider, et mes patrons ne connaissent rien à la programmation ce qu'ils veulent voir c le résultat.

ils me demandent des choses qui sont faisable en C/S mais en web faut faire autrement et c sa qu'ils ont du mal à comprendre

[olrt]

Si tu as bien conçu l'architecture de ton appli client/serveur tu devrais
avoir deux grands systèmes :

1°) La présentation.
=============
Elle est responsable de l'affichage des résultats sur le poste de
l'utilisateur et de l'interaction avec lui.
Tu dois définir une norme de structuration des messages échangés
avec le système des traitements.

Ainsi la couche de présentation s'occupe de "formatter" à l'écran les messages provenant de la couche de traitement (réponse) et s'occupe
de "générer" les messages provenant de l'interface utilisateur à
destination de la couche de traitement (question).

Concrètement on peut utiliser le langage XML comme langage de
structuration des messages.

Lorsque tu as fait ce travail de conception, il devient aisé de réaliser
des logiciels de présentation (cas d'un client riche).
Le plus simple étant le navigateur WEB (certains sont capables
de formatter un document XML grâce à une feuille de style XSLT).


2°) Les traitements.
=============
Ils constituent le côté "serveur de l'application".
Ils implantent les fonctions "métier" (création d'un contrat par exemple) et les fonctions "techniques" (pooling de connections avec une base de données par exemple).

[RDM]

en le faisant en web on peut tourner à plus de 100 personnes connecter simultanéments sur la base de données, sur certaines pages il peut y avoir plus de 100 requetes donc 100 * 100 = 10 000 c déjà pas mal, pour une base, et il faut que cela aussi rapide que du client serveur et aussi souple niveau utilisations.

100 requêtes sur une seule page ? c'est de la folie pur et simple, je doute que meme sur une application C/S tu es ce nombre de requête

De manière général il faut approcher le développement Web bien différemment que C/S classique. c'est une autre philosophie, un peu comme de paser de Dos a Windows.

Quant au problème lié au clavier ca c'est un faux problème. Les personnes qui avait des applis DOS disait la meme chose pour le Windows. Sauf que c'est just eune education a faire. en Windows pour passer d'un champ à l'autre on utilise Tab. En Web c'est pareil et puis on peut programmer quand meme des raccourcis clavier sur les pages, bref il y a assez de chose pour que l'on fasse des applications qui tienne la route sur du Web

[silvermoon]

Clement Cunin a dis :

Salut, tu devrait jeter un oeil sur WebStart.

Tout ce passe comme une application C/S classic, ton programme s'execute chez le client... mais a aucun moment tu n'ai obliger de l'installer(elle est automatiquement DL et executer par le client)

voir : http://faqjava.developpez.com/langag...GAGE_WEB_Start

oui je sais, c ceux qu'utilise les concurrents de la société ou je travaille, aucune des sociétés concurrentes n a fait l application, en pur web ( pur html) ils l ont tous fait en java et qui est accessible via webstart, j ai discuté à un salon avec les développeurs des sociétés concurrentes ils m ont tous dis qu'ils n avaient pas développer en html parce qu'il y a trop de contraintre et que c moins bien qu'une appli C/S comme java.


olrt a dis :

Si tu as bien conçu l'architecture de ton appli client/serveur tu devrais
avoir deux grands systèmes :

oui c ce que j ai fais avec des templates, le problème c qu'il s agit d'une application que l'on doit installer chez des clients, à mon travail je peux me permettre de faire des beaus trucs, et tout le reste parce que j ai une bonne machine et les dernières navigateurs.

mais chez les clients c différents : machine 150 Mhz, 32 M de ram, serveur de 400 Mhz avec 64 Mhz, IE 4 , .... donc je dois limiter mon appli au stricte minimum donc je ne peux pas forcément mettre les meme effet que dans une appli C/S, il y a des problèmes de sécurités qui handicape encore plus le problème et d autre encore ...

c pour cela que faire une application web pouvant à peu près rivaliser avec une appli C/S relève du miracle.

Pour RDM, excuse moi je me suis 100 fois tromper
mom écran le plus important n a pas 100 requete au plus une vingtaine, c déjà pas mal, et y a pas de ralentissement en C/S.

J'ai fais un test en web avec la meme base de données (oracle), et je ne fais afficher qu'une table de 60 champs, la page met 9 secondes pour s'afficher, c long très long, le poste client est un 120 Mhz avec 32 M ram, le serveur de l'appli web est un P4 1G9 avec 256 M de ram mais y a plein de truc qui tourne dessus, une base oracle, sqlserveur, mysql,interbase, ...
la base de données est sur un server de 500 Mhz avec 64 M de ram, la meme appli en C/S est instantané alors si on me dis qu'il faut changer mon architecture pour faire du web je veux bien mais comment je fais alors pour afficher instantanément ma page web avec mes 60 champs ??


Pour moi une application qu'un utilisateur attend c :
1- rapidité.
2- ergonomie.
3- simplicité.

nous avons des client très pointilleux et des services informatiques fainiant donc pas évident de convenir à tout le monde.

RDM a dis :

Quant au problème lié au clavier ca c'est un faux problème. Les personnes qui avait des applis DOS disait la meme chose pour le Windows. Sauf que c'est just eune education a faire. en Windows pour passer d'un champ à l'autre on utilise Tab. En Web c'est pareil et puis on peut programmer quand meme des raccourcis clavier sur les pages, bref il y a assez de chose pour que l'on fasse des applications qui tienne la route sur du Web

ce n est pas du tout un faux problème es tu déjà aller chez un client installer une version web de ton produit qui était précedement en C/S?
j ai eu de nombreux commentaire, à ce sujet par nos clients.

exemple :
en C/S : quand tu es dans tableau tu peux écrire dans ton tableau sur la ligne A et descendre avec les flèches sur la ligne B très rapidement.
en Web : quand tu es dans un tableau tu peux écrire dans ton tableau sur la ligne A mais pour descendre sois tu utilises, tab jusqu en fin de ligne , c long sois faut utiliser la souris , c long aussi, donc c un retour en arrière.

si tu as une solution en web qui est aussi facile qu en C/S donne la moi, je serais très heureux de l'utiliser.

[neo.51]

Tu peux faire du développement web avec des JSF(java) ou des webforms(ASP.NET) qui sont des composant web gérés comme des objets, tu peux ainsi créer ton propre composant qui hérite des composant de base et faire des controles avancés.

[DidiLogic]

Il me semble que tu as tout intérêt à essayer une architecture N-Tiers.
- application clientes riches : permettant le traitement en local d'une partie des données (tris/recherches/graphiques/ regles de gestion/ ...)
- possibilité de faire des mises à jour automatiques des appli clientes
- optimisation du traffic réseau (compression/cryptage/cache local)
- réduction du nombre de licences BD, seul l'application serveur est connectée

Si tu utilises Delphi ou C++Builder, tu as un vaste choix :
Midas / ASTA / Midware / dbOverNet / RemObjects / kbmWab / ...
Jettes un coup d'oeil sur le site de Midware pour un schema très clair du principe de fonctionnement. www.overbyte.be

Sinon, ... bon courage.

DL

[RDM]

exemple :
en C/S : quand tu es dans tableau tu peux écrire dans ton tableau sur la ligne A et descendre avec les flèches sur la ligne B très rapidement.
en Web : quand tu es dans un tableau tu peux écrire dans ton tableau sur la ligne A mais pour descendre sois tu utilises, tab jusqu en fin de ligne , c long sois faut utiliser la souris , c long aussi, donc c un retour en arrière.

En Web on ne peut pas calcquer ce que l'on avait en CS, si tu fais ca c'est que tu n'as pas compris l'archi et la cinématique web. il faut s'adapter a cette architecture. donc le coup des tableaux en web, on oublie, mais y a d'autres facons de faire qui peuvent tout aussi rapide.

[silvermoon]

je suis tout à fait d'accord avec ce que vous dites.

mais faut que sa plaise à mes patrons et aux clients et c pas gagner, parce qu'il ne connaissent rien au web et n'arrive pas à s'imaginer que le web c différent du C/S j ai beau leur répété 100 fois par jours sa ne rentre pas.



Moi j ai l'habitude du web et je vais aussi vite que dans du C/S c juste une question d'habitude.

[nektarfl]

Je suis en effet très surpris car en effet, personne dans vos commentaires n'a parlé de WebObject et programmation en java.
Est-ce que la pomme vous rebute tant?
Je ne suis pas un pro de la programmation, mon métier, c'est la fabrication des ressorts, alors j'ai développé en 1 semaine, sur mon mac une petite appli de calcul : http://ressort.dyndns.org:4210
OK il n'y a pas de base de données derrière, mais on peut sans problème utiliser n'importe quelle base de données. En plus, j'ai une ligne ADSL à 128Ko en sortie, et les temps de réponse sont assez court malgré une trentaine de champs.
Ca tourne sur mon mac à 800Mhz.
PS: je n'ai jamais réussi à programmer en VB!!

[jmmolina]

En Web on ne peut pas calcquer ce que l'on avait en CS, si tu fais ca c'est que tu n'as pas compris l'archi et la cinématique web. il faut s'adapter a cette architecture. donc le coup des tableaux en web, on oublie, mais y a d'autres facons de faire qui peuvent tout aussi rapide.

Bonjour,

Désolé de faire remonter ce post mais je pense qu'il y a encore des choses à dire sur le sujet.

Pour ma part je ne suis pas du tout d'accord concernant cette approche que certains ont du Web. J'adopte la logique inverse, à savoir que c'est au Web, à son architecture, de s'adapter aux besoins des utilisateurs. Je suis d'ailleurs surpris que des experts comme Jakob Nielsen ne soient pas d'accord. Les interfaces telles qu'on les connaît aujourd'hui permettent aux logiciels d'être ergonomiques et puissants. L'utilisateur peut en quelques clics intéragir avec tel ou tel élément graphique de l'interface, derrière les traitements effectuées peuvent être très lourds en terme de ressources.

Les interfaces dites logiciels, les composants graphiques dont l'on dispose, sont adaptés et développés aux besoins de l'utilisateur. Le Web n'en est qu'à ses balbutiements et certains pronent d'inventer la roue à nouveau, à savoir des interfaces, des méthodes spécifiques pour le Web. C'est une erreur car le Web ne diffère en rien de votre Bureau. C'est l'idée qu'on s'en fait qui est différente, car jusqu'à aujourd'hui on n'utilisait le Web que pour cliquer quelques liens. Mais depuis quelques années déjà, on voit des applications dites en Ligne/Online qui miment certaines fonctionnalités propres aux logiciels "de Bureau": tableaux dynamiques (à la Excel), page properties (tab), éditeur HTML WYSIWYG à la place des simples TEXTAREA... C'est donc une limite du Web qui nous conduit à le voir comme quelque chose de différent.

Alors qu'une autre logique me dit, le Web n'est qu'un simple Bureau dans un navigateur qui permet d'accéder directement à Internet. Microsoft l'a bien compris lorsqu'il a introduit son fameux Active Directory et autres Desktop pseudo-Web. On retrouve cette petite magie dans les Webforms de .NET et dans tout un tas d'autres technologies. Car on s'est rendu compte que le couple DHTML-ASP/PHP... ne faisait pas un ménage suffisamment bon pour retrouver tout la puissance d'un logiciel classique, de Bureau.

si tu fais ca c'est que tu n'as pas compris l'archi et la cinématique web. il faut s'adapter a cette architecture

Non, il a tout à fait raison, bien au contraire. C'est à l'architecture de s'adapter. Il cherche simplement à répondre aux besoins de ses clients et souhaits de ses patrons. Hélas les solutions techniques utilisés ne sont pas adaptés et l'application finale ne peut donc répondre aux besoins. On se retrouve face à une erreur de conception grave que l'on retrouve dans 99% des applcations d'aujourd'hui. J'exagère bien entendu ^^

Donc pour moi la solution c'est d'utiliser une technologie qui permet de développer une application de Bureau dans un navigateur Web. ASP.NET, Java... PHP est à la traîne puisqu'ils n'en sont qu'à penser à une lib Widgets (GTK) et que la majorité des développeurs utilisent DHTML pour donner un semblant d'ergonomie à leurs applications. Je parle en connaissance de cause, c'est ce que je fais .

Actuellement je cherche une alternative à PHP/DHTML, les Webforms de .NET me semblent être la solution idéale et j'espère trouver d'autres technologies aussi puissantes et "innovantes" (sachant que tout a déjà été inventé).

Voilà j'espère avoir été assez clair, pour moi cette façon de penser n'est qu'une affaire de marketing. A savoir que certains experts ont besoin de s'en mettre plein les proches alors ils réinventent une roue qui a rapporté des millions à ses créateurs voilà bien des années, un peu comme certains l'ont fait lors de la Guerre de Troie. Et si ils n'en sont pas conscients c'est bien dommage, cela veut dire que Jakob Nielsen lui-même est un crétin . Mais je reste quand même son plus grand fan car c'est lui qui m'a introduit à l'ergonomie ^^

Bonne Année 2003 à tous et à toutes, que vous soyez Bureauphile ou Webophobe :p,
JM