Je concevons un logiciel qui doit faire fonctionner différentes pièces de matériel basées sur une planification, mais il doit également disposer d'une interface Web pour configurer les paramètres, configurer le planning et éventuellement contrôler manuellement le matériel. Je ne sais pas comment concevoir l'architecture de logiciels comme celle-ci.
Une pensée que j'ai eu était de créer un service Windows qui fait la communication avec le matériel et de "publier" des services Web via WCF, puis de disposer d'une application ASP.NET qui contrôle ensuite le service Windows via WCF. Cette approche semble être beaucoup de travail pour ce que j'essaie d'accomplir.
Quelqu'un pourrait-il me donner une certaine direction si c'est une bonne approche, et même me donner une meilleure façon de le faire si l'on existe?
merci! Joel
3 Réponses :
Vous pouvez instancier un point final WCF en tant que service TCP à partir du service Windows, comme expliqué sur MSDN: Comment: Hôte WCF dans un service Windows à l'aide de TCP .
à partir de là, il est relativement simple de consommer ce point final dans une application ASP.NET (identique à la consommation de tout autre point final de WCF).
En l'absence de toutes raisons convaincantes de faire autrement, c'est probablement l'approche que je prendrais. Votre seule autre option consiste à utiliser une autre forme d'IPC, telles que des fichiers mappés de mémoire ou des tuyaux nommés. WCF est beaucoup plus facile à monter et à courir.
C'est la solution que je venais. Cependant, je n'ai pas maintenant d'intégrer ASP.NET Web Server dans un service. Si cela vous oblige à utiliser toujours WCF pour la communication, cela peut toujours être la voie à suivre.
Ma question de suivi en ce qui concerne la WCF est la suivante: serait-il assez rapide pour être un intermédiaire entre l'interface utilisateur Web et le matériel? Je ne pense pas pouvoir attendre plusieurs secondes pour les réponses de la WCF.
@HJOELR: WCF est très rapide, même lorsque vous avez du cryptage et d'autres extensions allumées. Je suis habitué aux temps de réponse de l'ordre d'environ 1/4 de seconde des serveurs distants; Normalement, le seul retard est dû à la latence du réseau, et si tous les services fonctionnant sur la même machine ou au moins, le même réseau, la latence devrait être presque nulle.
@Aronner: C'est très rassurant! Merci pour les informations sur la vitesse de la WCF.
La seule préoccupation ici est la sécurité. IIS offre beaucoup de fonctionnalités que vous devrez peut-être reproduire; Si ce n'est pas au début, alors peut-être que lorsque vous souhaitez prolonger l'architecture. Mieux vaut essayer d'organiser des services Web dans IIS (qui a été testé pour la sécurité, a trouvé la perte, fixe et retirée plusieurs fois) que dans un service, si possible.
@PDR: Je ne suis pas vraiment sûr de ce que vous entendez par "Sécurité" ici; WCF utilise la même sécurité de niveau de message (avec authentification optionnelle, cryptage, etc.) si vous l'exécutez sur une liaison TCP ou HTTP. Cela n'utilise même pas vraiment une grande partie de la pile ASP.NET lorsque vous l'exécutez sous ASP.NET. La seule chose que vous ne recevez pas gratuitement est la sécurité du transport (SSL), que vous n'avez pas besoin si vous activez la sécurité du message. L'hébergement de WCF sur TCP n'est pas comme une main sur votre propre service TCP; Il y a déjà une API d'hébergement, il vous suffit de changer quelques liaisons.
En fait, c'était l'un des principaux objectifs du WCF - de pouvoir l'organiser n'importe où, sous quelque forme que ce soit. Vous pouvez même l'accrocher à MSMQ. Il n'y a vraiment aucun risque de sécurité significatif pour utiliser les liaisons TCP.
Vous pouvez simplement utiliser un fichier XML commun (ou quelque chose) que le service surveille les modifications. L'interface Web pourrait simplement lire / écrire ce fichier XML. Cela ne fonctionne bien que si le service et le site Web fonctionnent sur la même machine (vous pouvez le faire à travers un partage également, mais c'est une configuration supplémentaire et vous pouvez bien vouloir aller avec WCF dans ce cas).
Bonne pensée. Cependant, il doit y avoir une communication bidirectionnelle. Le site interroge sur les informations du service, mais le site Web doit également être en mesure de mettre à jour les paramètres et tels que le service.
Vous pouvez incorporer un serveur Web ASP.NET dans le service à l'aide de l'API d'hébergement ASP.NET, puis utilisez-le pour exécuter un site Web ASP.NET directement.
Notez que le site ASP.NET fonctionnerait dans une appdomaine distincte.
Vous devez toujours développer le site ASP.NET séparément. Cela n'empêche pas vraiment la nécessité de proposer un moyen de communication entre l'application ASP.NET et le service, cela vous permet de gérer tout le paquet sans IIS.
@Aronner: Vous pouvez simplement passer un MarshalbyRefObject qui expose le service à ApplicationHost.CreateApplicationHost et interagissez avec l'ASP.NET. (Le projet ASP.NET doit faire référence à l'assemblage du service)
C'est un concept intéressant. Je ne savais pas que c'était même possible. Je verrai si je peux regarder cela pour voir si cela fonctionnerait pour ma situation.
Vrai à propos de MarshalbyRefObject - bien qu'une fois que vous commencez à se mettre en disciation, il est plus facile d'accéder à WCF. Vous avez raison, cependant, cela peut être fait techniquement sans aucune des méthodes traditionnelles de l'IPC.
Pour des raisons de sécurité, la meilleure solution dépendra beaucoup de la configuration matérielle. Comment les machines acceptent-elles les demandes? Où votre site Web réside-t-il à l'égard de votre service Windows? Quels pare-feu sont impliqués? Pouvez-vous gérer plutôt un service Windows qui interroge un service Web et a également une interface utilisateur?
La machinerie accepte principalement les demandes via un ou plusieurs ports série (réseaux RS485). Le site Web pourrait être sur la même machine que le service, mais j'aime la capacité de les faire scinder si nécessaire. Le pare-feu ne sera probablement pas un problème dans ce cas car il sera tout sur le même réseau. Pouvez-vous expliquer ce que vous voulez dire être un "service Windows qui interroge un service Web et a aussi une interface utilisateur?" Je ne sais pas comment un service Windows pourrait avoir une interface utilisateur.
Si vous souhaitez héberger l'interface Web sur une machine différente, il n'y a pas d'alternative à votre pensée.
"Je ne sais pas comment un service Windows pourrait avoir une interface utilisateur." Eh bien, il ne faut pas, d'être juste. Mieux vaut avoir une application UI distincte qui utilise RPC pour parler au service. Mais ce que je voulais vraiment dire, c'est avoir un service Web et un site Web qui se connectent directement à la machine. Ensuite, sur un PC de contrôle, disposez d'un service Windows qui interroge le service Web lorsqu'un utilisateur peut se connecter via un navigateur sur le site Web.