WCF auto hébergement, hébergement via l'application Console

Question

J'ai vu des exemples, des exemples de code, etc pour l'auto d'hébergement des services WCF au sein d'une application de la console, service Windows, etc.

Ma question est, comment cela fonctionnera dans la production? Sera-t-il efficace? Est-ce que ça va évoluer? Je ne suis pas sûr, comment cela va fonctionner, donc l'autre question est, ce sera un seul thread? multi-thread? dois-je gérer le multi-threading? appdomains?

Je préfère l'hébergement avec la ligne de commande, le service Windows pour des raisons liées à l'application.

Answer 1

Un service Windows hébergeant un point de terminaison WCF convient aux petits services qui ne seront pas fréquemment touchés; vous n'avez pas à jouer avec IIS (qui peut être une douleur réelle IMO). Cependant, il n'y aura qu'un seul écouteur à écouter, donc ce n'est pas recommandé pour un service susceptible d'être touché à plusieurs endroits à la fois (utilisez IIS pour cela, il configure un pool d'applications qui peut gérer plusieurs requêtes simultanées). Ce modèle est bon pour l'interopérabilité entre deux machines; vous pouvez configurer l'hôte de service sur une boîte "définir et oublier" vivant dans un entrepôt quelque part, et appelez-le pour effectuer des tâches simples mais personnalisées comme le redémarrage, décharges de journaux, etc

Évitez d'avoir une application utilisateur (console ou autrement) héberger un point de terminaison de service, à l'exception des tests initiaux de preuve de concept. En plus de l'inconvénient de l'écoute unique, une application utilisateur DOIT être exécutée dans le contexte d'un utilisateur connecté (pas les utilisateurs du service, qui sont "connectés" dans le cadre du démarrage de Windows), et doit avoir un "keepalive" personnalisé surveillance; avec un service, on peut dire à Windows de simplement le redémarrer s'il plante, alors qu'il ne donne pas un truc à propos de l'effondrement d'une application utilisateur autre que d'empêcher ce programme de détruire tout le système d'exploitation (et de demander à l'utilisateur signaler l'accident).

Answer 2

Ma question est,
Sera-t-il efficace? Est-ce que ça va évoluer?

Oui et oui. Mais pour les applications à très grande échelle, vous devriez toujours considérer IIS (+ WAS).

donc l'autre question est, est-ce que ce sera un seul thread? multi-thread?

Ceci est déterminé par la configuration.

Answer 3

Sera-t-il efficace?

Cela dépend de l'implémentation du service, du nombre maximal de requêtes qu'il peut gérer dans un laps de temps spécifique. L'efficacité est une mesure relative: supposons que votre service est capable de traiter 20 messages/s, si votre exigence est de pouvoir traiter 10 messages/s, alors votre service est efficace. Mais si l'exigence est de 30, alors ce n'est pas le cas.

Échelle?

Encore une fois, il n'est pas lié à l'hébergement. Vos services sont-ils apatrides? Si ce n'est pas le cas, ils n'évolueront probablement pas beaucoup puisque l'équilibrage de la charge n'est pas possible.

Sera-t-il gérable?

Probablement pas: - vous devez avoir un utilisateur connecté sur le serveur pour exécuter l'application - il ne démarre pas automatiquement avec le serveur - il ne peut pas le redémarrage automatique en cas d'échec - il n'a pas créer des instances du service proactivement - elle ne fournit pas (sans code personnalisé) un moyen de vérifier la santé des services

instance unique? Plusieurs threads?

Si votre service ne maintient pas l'état entre les appels par client, puis configurez comme « une instance par appel et pas multithreading » -> Pas concurrency, haut débit

Si votre service ne maintenir l'état, puis configurez-le comme "une instance par session et multithreading" pour permettre à un client d'effectuer des appels simultanés. Faites attention aux problèmes de concurrence et protégez vos ressources.

Si votre service ne gère pas l'état par client mais garde certaines données globales stockées pour tous les appels, considérez la "instance unique par service et multithreading". Gardez à l'esprit les problèmes de concurrence possibles. En cela, vous pouvez aussi bien utiliser "une instance par appel" et garder le stockage global hors service.