可扩展(插件/插件)WCF服务主机的想法？

Question

我正在寻找有关如何构建可扩展WCF服务器(具有动态加载服务)的建议,最好使用System.Addins或MEF.

服务器应该托管实现最小"插件"API(StartService/StopService/GetStatus？/ etc)的任何WCF服务(包含在运行时加载的DLL程序集中).

这篇文章是一个好的开始.一些目标和要点讨论:

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

当然,其他想法总是受欢迎的;)

Answer 1

• 是的,AppDomain为每项服务使用隔离.您需要AppDomain隔离,以便在发生故障时不会删除正在运行的其他服务.

• 提供WCF目前所做的所有方式,通过编程或通过配置.由于ServiceHost实例不可序列化,因此编程访问很困难,因此跨应用程序域边界获取信息将是一件痛苦的事.

• 我想说有可能做到.但是,这基本上是复制Windows进程激活服务,因此您可能希望开始查找您的功能.

• 它对开发很有帮助,但说实话,我并不认为它具有重要的功能.它使代码变得复杂,以获得不太可测量的增益(IMO).我宁愿编写一个脚本来停止服务,复制文件,然后重新启动它,而不是使代码库过于复杂,并且总是必须观察程序集.

• 现在你在谈论IIS.您基本上可以让IIS托管您的服务,并在配置文件更改时回收它.

总而言之,似乎WAS和IIS为您提供了您想要的大部分内容(高度可用,隔离的应用程序域,配置等),因此您可能想问自己为什么要自己这样做.