可扩展（插件/插件）WCF服务主机的想法？

Question

我正在寻找关于如何构建可扩展的WCF服务器（使用动态加载的服务）的建议，最好使用System.Addins或MEF。

服务器应该托管实现最小“插件”API（StartService/StopService/GetStatus？/ etc）的任何WCF服务（包含在DLL程序集中，在运行时加载）。

This post是一个好的开始。一些目标和要讨论的要点：

• 对每个服务使用/不使用隔离的AppDomain？
• 如何配置每个服务（端点，传输协议）？ XML配置文件还是更好的选择？
• 程序集的延迟/延迟加载（服务请求到达时）？可能？有用？如何？
• 当磁盘上的文件发生变化时，程序集重装（对开发环境有用）;
• 磁盘配置更改时服务重启;

，当然，其他的想法总是欢迎;）

Answer 1

• 是，使用隔离AppDomain每个服务。您需要AppDomain隔离，以便在发生故障时不会关闭正在运行的其他服务。

• 通过编程或配置提供WCF当前所做的所有方式。编程访问很困难，因为ServiceHost实例不是可序列化的，所以通过应用程序域边界获取信息将会很痛苦。

• 我会说这是可能的。但是，这基本上是复制Windows Process Activation Service，所以你可能想开始寻找你的功能。

• 这对开发很有帮助，但说实话，我不认为这是一个重要的功能。它使代码变得复杂，以致于不太可测量的增益（IMO）。我宁愿编写一个脚本来停止服务，复制文件并重新启动它，而不是过分复杂的代码库，并且总是需要观察程序集。

• 现在你正在谈论IIS。你实际上可以让IIS托管你的服务，并且在配置文件改变时它会回收它。

之所以这么说，似乎WAS和IIS为您提供你最想要的（高度avaliable，孤立的应用程序域，配置等，等）什么，所以你可能要问，为什么你会想自己做这个。