我应该在IIS中托管我的WCF服务吗？

Question

所以我正在设计一个WCF服务。 我对WCF没有经验，我正在尝试决定它是应该在IIS中托管还是自定义Windows服务..还是其他一些选择？

需要考虑的事项：

• 它需要在启动时从数据库加载数据。
• 它需要跨请求维护这些数据，而不是每次都加载它。
• 它需要同时处理多个请求。
• 它需要尽可能地配置端点。
• 它会调用原生dll很多。

我怀疑在IIS中托管它会简化某些事情，但我不确定在这种情况下这是一个好主意。

我有哪些选择，它们的优缺点是什么？

Answer 1

你需要基本上看三个选项：

1）在IIS6中托管（Windows Server 2003/2003 R2）：在这种情况下，您只能托管HTTP协议 - 没有别的。 这本身就是一个很大的限制，你不能使用netTcp作为Intranet场景。

2）在IIS7 / WAS中托管（Vista，Server 2008）：这为您提供了更多支持协议的选项，并且托管环境起初看起来像是赢家。

3）自托管：在这种情况下，完全取决于您做任何您需要做的事情来托管和运行您的服务。

如果你现在抛出选项＃1（如果你只有IIS6可用，我总是使用自托管），那就是IIS7与自托管。

IIS7为您提供“按需激活”，例如您的服务代码始终不在内存中，但是一旦请求进入就会加载并实例化。这可能是一个加分。

另一方面，在IIS7 / WAS中托管会让您无法指定自己的端点 - 您的端点以及服务地址是您的“MyService.svc”文件所在的虚拟目录 - 期间。 你不能以任何方式，形状或形式改变它。

自托管可能看起来很多工作 - 但它确实为您提供了最大的灵活性：您可以随意选择协议，您可以按照自己喜欢的方式设置自己的寻址方案，并且您可以完全控制完成时。 如果您需要做一些额外的工作来托管服务，您可以引入自己的自定义ServiceHost，等等。

除非您只是稍微使用WCF，否则我总是会建议并投票支持自托管 - 如果您需要在Windows NT服务中始终运行WCF服务（这是生产环境的最佳解决方案） ，如果您正在开发/调试，您可以在控制台应用程序中完全托管您的WCF服务，您可以在闲暇时启动和停止。

所以简而言之：最后，如果你真的希望控制正在发生的事情，我总是建议自我托管。

一旦微软推出了新的“Dublin”Server-Addon， 可能会改变这种情况 - 可能是在.NET 4推出后的某个时候，可能是在2010年初 - 但现在还为时尚早。

希望这可以帮助。

渣

Answer 2

我自己更喜欢自托管服务（Windows服务）。 有了这个说，有正当理由去任何一种方式。

MSDN中有一些关于不同WCF托管策略的有价值文章 。

以下是您可能选择将IIS用作服务主机的原因。

Answer 3

我会说没有IIS7和WAS你不能使用IIS托管基于HTTP的端点。 因此，您很可能希望自我主持灵活性。

至于您的数据注意事项，任何服务都可以使用状态进行编码，以便缓存数据等。

多个请求将要求您使用WCF并发。 您想在服务主机上设置属性：

[System.ServiceModel.ServiceBehavior(UseSynchronizationContext = false,
    InstanceContextMode = System.ServiceModel.InstanceContextMode.PerCall,
    ConcurrencyMode = System.ServiceModel.ConcurrencyMode.Multiple)]
public class MyService : IMyService
{
}

WCF是一个大野兽，我建议你看看Juval Lowy的书以及你能得到的任何其他东西，你不会在一天内学到它。

Answer 4

也许有点偏离主题，但它确实解决了四个问题。

如果您最终使用自托管并且需要尽可能“关于端点”进行配置，那么您可能需要查看托管服务引擎 。 MSE是Microsoft Services创建的一个开源产品，可让您虚拟化您的服务。 基本上，它是一个WCF主机，它使用自己的存储库中的元数据来公开服务。 一些功能包括：支持服务的并排版本控制，启用/禁用服务操作的能力，将操作映射到端点的能力，将策略应用于操作的能力。

我不确定它是否符合您的需求，但值得一看 - 特别是如果您需要非常可配置。