IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

ASP.NET Discussion :

[VB.NET] appli de gestion d'une ligne d'assemblage ?


Sujet :

ASP.NET

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé Avatar de apoingsfermes
    Profil pro
    Inscrit en
    Février 2006
    Messages
    54
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Février 2006
    Messages : 54
    Par défaut [VB.NET] appli de gestion d'une ligne d'assemblage ?
    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 !

  2. #2
    Rédacteur
    Avatar de dev01
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    2 451
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2004
    Messages : 2 451
    Par défaut Re: .NET pour une appli de gestion d'une ligne d'assemblage
    Citation Envoyé par apoingsfermes

    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/

  3. #3
    Membre confirmé Avatar de apoingsfermes
    Profil pro
    Inscrit en
    Février 2006
    Messages
    54
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Février 2006
    Messages : 54
    Par défaut
    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

  4. #4
    Membre expérimenté Avatar de del-dongo
    Inscrit en
    Mai 2003
    Messages
    147
    Détails du profil
    Informations forums :
    Inscription : Mai 2003
    Messages : 147
    Par défaut
    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...

  5. #5
    Membre confirmé Avatar de apoingsfermes
    Profil pro
    Inscrit en
    Février 2006
    Messages
    54
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Février 2006
    Messages : 54
    Par défaut
    Citation Envoyé par 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..
    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...

  6. #6
    Expert confirmé
    Avatar de neguib
    Profil pro
    Inscrit en
    Mai 2005
    Messages
    3 627
    Détails du profil
    Informations personnelles :
    Âge : 65
    Localisation : Suisse

    Informations forums :
    Inscription : Mai 2005
    Messages : 3 627
    Par défaut
    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

  7. #7
    Membre confirmé Avatar de apoingsfermes
    Profil pro
    Inscrit en
    Février 2006
    Messages
    54
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Février 2006
    Messages : 54
    Par défaut siute et fin
    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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [VB.NET] Repeater plusieurs items sur une ligne
    Par diaboloche dans le forum ASP.NET
    Réponses: 5
    Dernier message: 09/03/2007, 13h53
  2. Réponses: 1
    Dernier message: 08/09/2006, 18h23
  3. Réponses: 14
    Dernier message: 24/05/2006, 16h05
  4. [VB NET]: Empecher la suppression d'une ligne d'un Datagrid
    Par ADONET dans le forum Windows Forms
    Réponses: 1
    Dernier message: 13/02/2006, 00h40
  5. Réponses: 8
    Dernier message: 14/05/2004, 11h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo