|
| Iniciado por youenn.ballouard, 10,mar. 2006 16:54 - 6 respuestas |
| |
| | | |
|
| |
Publicado el 10,marzo 2006 - 16:54 |
Bonjour,
Je cherche des informations sur le 3-tiers de Windev (couche graphique,
applicative et bdd) ou alors sur une solution me permettant de faire du
3 tiers avec la couche graphique en Windev + une couche applicative sur
un autre système (de préférence sous linux)
+ SGBD Mysql.
Merci d'avance de vos conseils.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Youenn BALLOUARD
Chef de Projets Informatiques
Groupe BERGUE
Tel. 02.41.96.68.77
Fax. 02.41.96.68.53
youenn.ballouard@findis.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| |
| | | |
|
| | |
| |
Publicado el 10,marzo 2006 - 17:15 |
De ce que j'en ai compris: il y a pas mal de truc à programmer encore mais les fonctions de sérialisation simplifient les échanges. D'expérience bien réfléchir avant de mettre en place cette solution, l'architecture même de Windev éliminant dans 99% des cas ce besoin. Car on l'oublie trop souvent, la puissance de 'l'IHM' des applications que l'on crée par Windev libère d'un tas de contraintes par rapport aux langages code-code (java, C++, C#...). Une belle IHM bien blindée, des FichierVersEcran et EcranVersFichier et souvent c'est ça en fin de compte la demande initiale. Sinon j'vaias quand même fait faire du 3 tiers pur et dur (en Webdev, pour des raisons de sécurité des données qui devaient être sur un serveur sécurisé séparé par rapport à l'appli) avec la version 9, quand on est passé en 10 les fonctions de sérialisation on du enlever 50% des lignes de codes !!!! |
| |
| |
| | | |
|
| | |
| |
Publicado el 10,marzo 2006 - 17:28 |
Phil a écrit :
De ce que j'en ai compris: il y a pas mal de truc à programmer encore mais les fonctions de sérialisation simplifient les échanges. D'expérience bien réfléchir avant de mettre en place cette solution, l'architecture même de Windev éliminant dans 99% des cas ce besoin. Car on l'oublie trop souvent, la puissance de 'l'IHM' des applications que l'on crée par Windev libère d'un tas de contraintes par rapport aux langages code-code (java, C++, C#...). Une belle IHM bien blindée, des FichierVersEcran et EcranVersFichier et souvent c'est ça en fin de compte la demande initiale. Sinon j'vaias quand même fait faire du 3 tiers pur et dur (en Webdev, pour des raisons de sécurité des données qui devaient être sur un serveur sécurisé séparé par rapport à l'appli) avec la version 9, quand on est passé en 10 les fonctions de sérialisation on du enlever 50% des lignes de codes !!!!
Mon problème c'est que mon groupe est reparti sur 20 sites en France
relié en ADSL. ce qui représente 170 postes
et le problèmes c'est si je modifie l'appli je dois mettre à jour tous
mes postes.
L'install réseau ou HTTP ne réponds pas entièrement à mes besoins car il
y a un besoin énorme au niveau réseau
Avec une apli trois tiers, je déporte l'applicatif mais pas l'IHM !
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Youenn BALLOUARD
Chef de Projets Informatiques
Groupe BERGUE
Tel. 02.41.96.68.77
Fax. 02.41.96.68.53
youenn.ballouard@findis.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| |
| | | |
|
| | |
| |
Publicado el 10,marzo 2006 - 18:04 |
Le 3-tiers ne résoud qu'une partie de ton problème : quid de la mise à jour de l'interface ?
Que ce passe-t'il en cas de mise à jour du protocole entre les 2 premiers tiers ? ?
Pour résoudre ce genre de soucis, nous avons mis tout le monde en client léger. De plus, les applications sont installées sur un NAS, ce qui nous apporte les gains suivants:
les applications ne sont installées qu'une seule fois,
les mises à jour se bornent à déposer la WDL à jour dans un répertoire, et une tâche planifiée recopie cette WDL sur le NAS dans la nuit,
Les échanges de données entre les applications et le SGBD se font sur le réseau local ( donc chez nous en gigabit ethernet), et seul l'affichage est déporté sur le client final,
Il n'y a rien à faire au niveau programmation,
Le débit nécessaire n'est pas très important.
Si en plus tu ajoutes un accès Citrix, tes applications sont disponible depuis n'importe où, pourvu qu'un accès internet et un navigateur soit disponible.
Enfin deux derniers petits bénéfices, mais qui n'ont rien à voir ici : l'administration du réseau est largement simplifié, et comme les serveurs sont protégés par un gros onduleur, personne ne pert son travail en cours en cas de coupure de courant.
Seul bémol, il faut éviter les interfaces trop riches ( dégradés, bitmap... ).
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Publicado el 10,marzo 2006 - 18:04 |
Effectivement ça me semble logique.
D'un autre côté, 170 postes c'est finalement assez peu ! Tout dépend de la fréquence de modification de l'application et surtout si tous les utilisateurs se connectent initialement exactement en même temps, genre ils allument tous à 8h00 le matin (l'automatic update ne gère pas de file décalée !)
Mais bon, moi si j'avais à faire, je commencerait pas une architecture habituelle; avec ADSL ça va vite quand même. Et ça posait problème, alors je passerai en 3 tiers.
Eventuellement voir s'il n'est pas possible de ne mettre à jour que les 20 "serveurs" des sites, les postes des utilisateurs se référant alors à ces serveurs. |
| |
| |
| | | |
|
| | |
| |
Publicado el 13,marzo 2006 - 09:57 |
Phil a écrit :
Effectivement ça me semble logique.
D'un autre côté, 170 postes c'est finalement assez peu ! Tout dépend de la fréquence de modification de l'application et surtout si tous les utilisateurs se connectent initialement exactement en même temps, genre ils allument tous à 8h00 le matin (l'automatic update ne gère pas de file décalée !)
Mais bon, moi si j'avais à faire, je commencerait pas une architecture habituelle; avec ADSL ça va vite quand même. Et ça posait problème, alors je passerai en 3 tiers.
Eventuellement voir s'il n'est pas possible de ne mettre à jour que les 20 "serveurs" des sites, les postes des utilisateurs se référant alors à ces serveurs.
Bonjour,
En effet 170 c'est peu. En ce qui concerne la solution de mettre une
installation sur chaque "serveur site" c'est déjà le cas mais je
recherche des solutions disons plus rapides de mises en places de
modifications d'où mes questions!
Encore merci de tes réponses.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Youenn BALLOUARD
Chef de Projets Informatiques
Groupe BERGUE
Tel. 02.41.96.68.77
Fax. 02.41.96.68.53
youenn.ballouard@findis.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| |
| | | |
|
| | |
| |
Publicado el 13,marzo 2006 - 09:58 |
Frédéric DEMILLY a écrit :
Le 3-tiers ne résoud qu'une partie de ton problème : quid de la mise à jour de l'interface ?
Que ce passe-t'il en cas de mise à jour du protocole entre les 2 premiers tiers ? ?
Pour résoudre ce genre de soucis, nous avons mis tout le monde en client léger. De plus, les applications sont installées sur un NAS, ce qui nous apporte les gains suivants:
les applications ne sont installées qu'une seule fois,
les mises à jour se bornent à déposer la WDL à jour dans un répertoire, et une tâche planifiée recopie cette WDL sur le NAS dans la nuit,
Les échanges de données entre les applications et le SGBD se font sur le réseau local ( donc chez nous en gigabit ethernet), et seul l'affichage est déporté sur le client final,
Il n'y a rien à faire au niveau programmation,
Le débit nécessaire n'est pas très important.
Si en plus tu ajoutes un accès Citrix, tes applications sont disponible depuis n'importe où, pourvu qu'un accès internet et un navigateur soit disponible.
Enfin deux derniers petits bénéfices, mais qui n'ont rien à voir ici : l'administration du réseau est largement simplifié, et comme les serveurs sont protégés par un gros onduleur, personne ne pert son travail en cours en cas de coupure de courant.
Seul bémol, il faut éviter les interfaces trop riches ( dégradés, bitmap... ).
Frédéric.
Bonjour,
Tu as tout a fait raison mais j'envisage plus souvent des modifications
de code que d'interface par contre je ne comprends pas bien l'histoire
du protocole entre les deux premières couches car c'est quelque chose
que l'on ne change pas comme ça !!!
Oui il existe toujours la solution des clients légers ... voir les
clients riches... Mais ce que je fais ici c'est plus de la veille
technologique que de la résolution de problèmes.
Merci beaucoup de tes réponses
cordialement.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Youenn BALLOUARD
Chef de Projets Informatiques
Groupe BERGUE
Tel. 02.41.96.68.77
Fax. 02.41.96.68.53
youenn.ballouard@findis.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| |
| | | |
|
| | | | |
| | |
|