Discussion :

[apoingsfermes]

Bonjour,
Je suis devant un choix de conception délicat. Je dois réaliser une application qui controle une ligne d'assemblage dans une usine, avec VB, et une architecture trois-tiers.
Les postes opérateurs sont des clients qui affichent des informations differentes en fonction du poste.
L'application coté serveur gère, en plus de l'affichage de ces postes, des informations provenant de scanners, d'autres logiciels, etc.
Il faut donc que le serveur soit en mesure de modifier l'affichage des postes en fonction, par exemple, de données provenant des capteurs sur la ligne d'assemblage.

Deux questions :
1) Puis-je utiliser des clients légers, avec ASP.NET ? A priori, avec cette technologie il est impossible au serveur de communiquer avec des clients spécifiques. Une manière de contourner le problème est de rafraichir les pages des postes clients toutes les X secondes, mais cette solution me parait du bidouillage. En plus de cela, l'appli côté serveur doit etre capable de tourner indépendamment des clients, pour recevoir et traiter les infos provenant des autres logiciels...

2) Dans le cas de clients lourds pour les postes opérateurs, quelle est la technologie à utiliser ? Existe-t-il des objets .NET du genre "socket" qui permenttent de gérer des communications identifiées et bilatérales entre serveur et clients ?

Merci !

[dev01]

2) Dans le cas de clients lourds pour les postes opérateurs, quelle est la technologie à utiliser ? Existe-t-il des objets .NET du genre "socket" qui permenttent de gérer des communications identifiées et bilatérales entre serveur et clients ?

Merci !

Oui en .NET tu as tout a fait les sockets. Mais dans ton cas je te conseil d'aller jeter un coup d'oeil du coté du remoting avec cet article :
http://defaut.developpez.com/tutoriel/dotnet/remoting/

[apoingsfermes]

OK, donc pas de problème avec des clients lourds, la technologie existe.

Par contre, c'est réellement infaisable en client léger ? J'ai besoin de l e savoir pour convaincre es décideurs

[del-dongo]

je serais très interessé (par simple curiosité intellectuelle) sur la facon d'implémenter une telle solution...
Tes applis clientes seront en mode console..?
comment se fait concrtement la différence entre client léger et client lourds...car dans le cas d'un protocole maison via socket, les clients devront au moins avoir l'intelligence pour décoder les trames et renvoyer les informations au serveur...est ce sur ce principe qu'il faudrait partir..?
ps : n'y a t'il pas de framework déja existant pour ce type de projet.., ca me semble un peu lour à implémenter complètement...

[apoingsfermes]

je serais très interessé (par simple curiosité intellectuelle) sur la facon d'implémenter une telle solution...
Tes applis clientes seront en mode console..?
comment se fait concrtement la différence entre client léger et client lourds...car dans le cas d'un protocole maison via socket, les clients devront au moins avoir l'intelligence pour décoder les trames et renvoyer les informations au serveur...est ce sur ce principe qu'il faudrait partir..?
ps : n'y a t'il pas de framework déja existant pour ce type de projet..

L'appli serait un programme indépendant tournant sur le serveur, et dialoguant avec le matériel de la ligne d'assemblage et la base de données (pour la traçabilité). Les clients qui affichent les infos sur les postes opérateurs seraient des clients lourds, qui se connecteraient à l'appli tournant sur le serveur, une fois, au démarrage de la ligne.

Si j'utilise les sockets pour la comm, je ne vois pas d'autre solution que de définir mon propre protocole. je sais faire, mais comme tu dis, "c'est lourd". Et j'ai un petit mois pour développer ça...

Je n'ai pas regardé en détail le remoting, mais ca semble intéressant.
Je ne sais pas si c'est exactement ce que je recherche, mais j'imagine que ce n'est pas la première fois que ce genre de problème se pose, dans l'énorme communauté .NET !

Ce dont j'aimerais être sûr, c'est qu'utiliser des clients légers (ASP.NET) n'est pas possible. J'ai l'impression que ce langage n'est absolument pas fait pour ce genre d'applications, et qu'il faudrait trop de bidouilles pour arriver à un résultat pas souple du tout. L'appli doit tourner 24h/24...

[neguib]

Comme tu as reçu ta réponse pour la partie Client lourd, je deplace ton sujet dans le forum ASP.Net, pour que tu puisse obtenir une reponse judicieuse en ce qui concerne la partie Client léger

[apoingsfermes]

mon problème est résolu !
Mon client est tellement attaché à la solution "client léger" qu'il est prêt à supprimer tout ce qui peut gêner la réalisation d'une application avec cette technologie
C'est pas la meilleure façon de résoudre les problèmes, mais ça m'arrange bien 8)
Merci tout le monde