Discussion :

[jmguiche]

Je ne suis pas très loin de penser cela, mais dans un contexte totalement différent ...

Je suis actuellement dans un environnement Mainframe ( IBM z/OS et DB2 ) et chez nous s'opposent :

- une architecture actuelle "classique" à deux couches :

1) IHM (typiquement un navigateur) sur le poste de travail

2) moniteur transactionnel IMS/TM sur le mainframe avec des programmes écrits en COBOL et des accés SQL intégrés

Le lien étant fait par un "middleware" maison de type CORBA

- une architecture future à trois couches :

1) IHM (typiquement un navigateur) sur le poste de travail

2) serveur de type Websphere avec des programmes écrits en JAVA qui détiennent les règles "métier"

3) procédures stockées sur le DB2 z/OS pour l'accès aux données

La faisabilité et les performances de l'architecture à trois couches me semblent vraiment problématiques ...

Il est dommage que l'architecture 3 tiers suivante ne soit pas envisagée :

• IHM / poste de travail
• Server type webspher pour la génération de pages
• SGBD contenant l'ensemble des règles de gestions et les vues pour servir le générateur de pages. mais je ne connais pas le langage procédural de DB2 pour savoir si ça marche avec ce sgbd.

L'ihm sur un navigateur (html), c'est à la mode, mais c'est pauvre, pas tres interactif et pas mal consommateur en bande passante. Pour faire de l'interactif, on est obligé de rajouter une couche de javascript par dessus tout ça et là, c'est cher !

[orafrance]

L'ihm sur un navigateur (html), c'est à la mode, mais c'est pauvre, pas tres interactif et pas mal consommateur en bande passante. Pour faire de l'interactif, on est obligé de rajouter une couche de javascript par dessus tout ça et là, c'est cher !

mouais, enfin ça c'est la vision des applis web du siècle dernier, l'IHM s'est grandement améliorée et arrive à la hauteur du client/serveur sans dégradation excessive des perfs

[jmguiche]

mouais, enfin ça c'est la vision des applis web du siècle dernier, l'IHM s'est grandement améliorée et arrive à la hauteur du client/serveur sans dégradation excessive des perfs

Quand je dis chere, c'est en temps de développement, surtout si c'est pour être à la hauteur du C/S.
Et plus c'est beau, plus c'est consommateur en bande passante. Le cout pour afficher un simple tableau, une grille, que l'utilisateur peut modifier (ce qui est quand même assez banal), ça chiffre.

Avec des architecture 3 tiers venant du C/S (forms pour ne pas le citer), j'ai des volumes d'échanges faible (par rapport à la même chose ou comparable en html/javascript) et les temps de réponses sont immédiat, ce que je n'ai pas en html/javascript.

Si tu as des outils pour faire du client léger facilement et avec une bonne ergonomie, ça m'interesse et sans consommer de la bande passante comme si il n'y avait pas de limites, ça m'interesse encore plus !

[orafrance]

Quand je dis chere, c'est en temps de développement, surtout si c'est pour être à la hauteur du C/S.

Forms par exemple propose exactement la même interface en C/S ou en Web, ce qui démontre que le coût peut être le même

Et plus c'est beau, plus c'est consommateur en bande passante. Le cout pour afficher un simple tableau, une grille, que l'utilisateur peut modifier (ce qui est quand même assez banal), ça chiffre.

Ca consomme rien, c'est toujours le client qui se charge de générer la page ou alors elle est statique et c'est qu'un transfert de données qui n'est guère plus couteux qu'un SELECT via SQL*Plus... même moins puisque dans des tableaux tu peux charger les lignes par tranche pour limiter le trafic justement

Avec des architecture 3 tiers venant du C/S (forms pour ne pas le citer), j'ai des volumes d'échanges faible (par rapport à la même chose ou comparable en html/javascript) et les temps de réponses sont immédiat, ce que je n'ai pas en html/javascript.

J'étais admin Oracle Appli et je n'ai pas vu d'écart flagrant de consommation réseau entre OA 10.7 et 11i... je pense que c'est plutôt les servlets auxquelles tu penses et pas au HTML

Si tu as des outils pour faire du client léger facilement et avec une bonne ergonomie, ça m'interesse et sans consommer de la bande passante comme si il n'y avait pas de limites, ça m'interesse encore plus !

Forms

[jmguiche]

J'étais admin Oracle Appli et je n'ai pas vu d'écart flagrant de consommation réseau entre OA 10.7 et 11i... je pense que c'est plutôt les servlets auxquelles tu penses et pas au HTML



Forms

Non, c'était bien du html, du xml et du javascrpit qui consommait la bande passante.

J'ai tendence à mettre forms dans la catégorie client lourd, en oppositon au client léger html/javascript. Mais bon... Nous sommes d'accord sur le fait que ça marche étonnament bien, surtout quand on compare ! Et forms, comme tu le dit, c'est "une appli web du siecle dernier" !

[ylarvor]

Je voudrais juste rappeler l'interet principal des clients web par rapport aux clients lourd ou client-serveur. Il n'a pas à deployer de client sur le poste client et ainsi, un bug corrigé est corrigé pour tous... c'est un progres essentiel dans la maintenance des applications...

[jmguiche]

Je voudrais juste rappeler l'interet principal des clients web par rapport aux clients lourd ou client-serveur. Il n'a pas à deployer de client sur le poste client et ainsi, un bug corrigé est corrigé pour tous... c'est un progres essentiel dans la maintenance des applications...

Oui, c'est une idée assez répendue et plutôt préconçue.

Quand elle était répendu il était déja possible de mettre les applicatifs sur des serveur de fichiers partagés, ensuite de mettre des mécanismes qui, à la connexion, telechargeaient autmatiquement une nouvelle version si necessaire ou dispatchaient la nouvelle version sur les serveurs de fichiers. Du msi avant l'heure quoi.

Maintenant, la majorité de ces outils fonctionnent en 3 tiers, il n'y à a télécharger qu'une éventuelle applet (exemple de forms), cela se fait automatiquement en cas de changement de version.

Bref, c'est une idée fausse, toute faite et qui, bien que répétée à tout bout de champ, n'en reste pas moins fausse.

[lunatix]

oui, enfin, c'est beaucoup moin trivial que une application web. gérer le coté multiplateforme (y compris entre des versions de windows), la gestion des mises a jour n'est pas si simple !

[Luc Orient]

Client lourd / client léger ... dur de choisir ...

... alors pourquoi pas le meilleur des deux mondes ... le client riche ...

[jmguiche]

oui, enfin, c'est beaucoup moin trivial que une application web. gérer le coté multiplateforme (y compris entre des versions de windows), la gestion des mises a jour n'est pas si simple !

Si c'est une réponse à mon post, je ne comprend pas.

[orafrance]

Quand elle était répendu il était déja possible de mettre les applicatifs sur des serveur de fichiers partagés, ensuite de mettre des mécanismes qui, à la connexion, telechargeaient autmatiquement une nouvelle version si necessaire ou dispatchaient la nouvelle version sur les serveurs de fichiers. Du msi avant l'heure quoi.

que celui qui n'a jamais eu l'appel d'un utilisateur qui n'a pas la bonne version de fmx ou pll me jette la première pierre

l'intérêt du client léger c'est de s'enlever une point faible de la formidable chaine de l'informatique : l'erreur humaine qui consiste à ne pas récupérer les dernières mises à jour, supprimer un fichier par mégarde ou autres joyeusetés. Et s'il y avait des alternatives leur coût n'est en rien comparable avec le déploiement d'une solution web

Si c'est une réponse à mon post, je ne comprend pas.

le client/serveur impose que tous les postes clients ont le même OS quand le client léger impose au pire d'avoir le même navigateur

Et quand tu fais une migration NT4/Windows 2000 j't'explique pas le malaise pour les clients lourds

Client lourd / client léger ... dur de choisir ...

... alors pourquoi pas le meilleur des deux mondes ... le client riche ...

la cliente allégée en matière grasse sinon

[jmguiche]

...

OK, je prenais ça pour forms dans sa version actuelle du produit !

Et pour les approches "antiques", il y avait des solutions ! Fin des année 90, au top du "le C/S, c'est pas bô, le client léger, c'est mieux", il était plus simple de faire du C/S que du client léger et forms faisait déjà de 3 tiers.

Aujourd'hui, à l'époque du "le client lourd c'est pas bô, le client léger c'est mieux." je crois qu'il est plus simple de faire du forms 3 tiers que du client leger (je ne parle que d'informatique de gestion et de l'ensemble de la chaine développement + prod.).

[orafrance]

j'vois pas bien la différence entre forms 3 tiers et client léger sur le poste client tu n'as rien à part le navigateur on est bien d'accord ?

[jmguiche]

j'vois pas bien la différence entre forms 3 tiers et client léger sur le poste client tu n'as rien à part le navigateur on est bien d'accord ?

Si, on a l'applet forms, et les gens qui parlent de client léger parlent de page html/javascript.
Donc, forms 3 tiers est ce du client lourd ou du client léger ou du client riche ? Je laisse aux lexicologues le soin d'en débattre, c'est un problème de vocabulaire.
Quand je me ballade dans la littérature, c'est probablement du client riche...

[SQLpro]

On dérive sur un débat client lourd versus client léger. Je voudrais juste rappeler que Java avec sa machine virtuelle et mieux MS avec sa plateforme Dotnet ont tous deux réussit à nous faire du client lourd facilement déployable !!!!

A +

[Keihilin]

Oui c'est vrai, ça fait quelques pages que le débat dérive fortement...

Pour recentrer sur ce que pourrait être l'avenir des bases de données, on pourrait se poser la question :

Pourquoi les bases de données n'ont pas réussit à s'imposer comme serveurs d'applications ? Que leur manque-t-il pour s'imposer face aux plateformes Java ou Dotnet ?

[jmguiche]

Les SGBD peuvent déjà servir de serveur d'application.
Ils servent de server pour les règles de gestion pour tout ceux qui font du "thick database" (en transac ou en PL), le server d'application lui même ne faisant que de la présentation. Ce n'est qu'une partie de la réponse.

Oracle, avec l'offre APEX, propose un systeme ou le sgbd fait aussi totalement server d'application, avec des références tout à fait raisonnables.
Là pour quelques exemples. Si quelqu'un a un retour d'experience réel ça serait interressant.

Je pense que le c'est une voie plus que raisonnable pour la technique. Les fermes de servers onctionne de mieus en mieux, les gains que permettent d'éviter l'empilement de techno d'origines diverses son énorme, etc.
Enfin, j'ai tout un laïus plus haut là dessus.