Des idées pour un hôte de service WCF extensible (addins/plugins)?

Question

Je cherche des suggestions sur la façon dont je peux construire un serveur WCF extensible (avec des services chargés dynamiquement), de préférence en utilisant System.Addins ou MEF.

Le serveur doit héberger n'importe quel service WCF (contenu dans les assemblys DLL, chargé en exécution) qui implémente une API "plugin" minimale (StartService/StopService/GetStatus?/Etc).

This post est un bon début. Quelques objectifs et points à discuter:

• Utilisez/n'utilisez pas un AppDomain isolé pour chaque service?
• Comment configurer chaque service (points de terminaison, protocoles de transport)? Fichier XML-config ou une meilleure alternative?
• Chargement différé/paresseux des assemblages (lorsqu'une demande de service arrive)? Possible? Utile? Comment?
• Rechargement de l'assemblage lorsque le fichier est modifié sur le disque (utile pour l'environnement de développement);
• Redémarrage du service lorsque la configuration sur le disque change;

et, bien sûr, d'autres idées sont toujours les bienvenus;)

Answer 1

• Oui, utiliser un AppDomain isolé pour chaque service. Vous avez besoin de l'isolation AppDomain pour ne pas supprimer les autres services en cours d'exécution.

• Offrez toutes les fonctionnalités de WCF, que ce soit par programmation ou par config. L'accès programmatique est difficile, car l'instance ServiceHost n'est pas sérialisable, donc l'obtention des informations à travers la limite du domaine de l'application va être pénible.

• Je dirais que c'est possible. Cependant, ceci est fondamentalement la réplication Windows Process Activation Service, ainsi vous pourriez vouloir commencer à regarder là pour votre fonctionnalité.

• C'est utile pour le développement, mais honnêtement, je ne pense pas que ce soit une fonction aussi importante. Cela complique votre code pour un gain qui n'est pas trop mesurable (IMO). Je préfèrerais écrire un script qui arrêtera le service, copiera le fichier et le relancera au lieu de surcharger le code et de toujours regarder l'assemblage.

• Maintenant, vous parlez d'IIS. Vous pouvez essentiellement avoir IIS héberger votre service et il va le recycler lorsque le fichier de configuration change.

Tout cela étant dit, il semble que WAS et IIS vous offrent plus de ce que vous voulez (domaines, d'applications isolées très avaliable, configuration, etc, etc), vous voudrez peut-être vous demander pourquoi vous voulez pour le faire vous-même.