当前位置:  开发笔记 > 编程语言 > 正文

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

如何解决《可扩展(插件/插件)WCF服务主机的想法?》经验,为你挑选了1个好方法。

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

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

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

对每项服务使用/不使用隔离的AppDomain?

如何配置每个服务(端点,传输协议)?XML配置文件还是更好的选择?

组件的延迟/延迟加载(当服务请求到达时)?可能?有用?如何?

磁盘上的文件更改时的程序集重新加载(对开发环境有用);

磁盘上的配置更改时重新启动服务;

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



1> casperOne..:

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

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

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

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

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

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

推荐阅读
路人甲
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有