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

时间:2022-11-19 10:07:50

So I'm designing a WCF service. I'm unexperienced with WCF, and I'm trying to decide whether it should be hosted in IIS, or a custom Windows service.. Or some other option?

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

Things to consider:

需要考虑的事项:

  • It needs to load data from a database on startup.
  • 它需要在启动时从数据库加载数据。

  • It needs to maintain this data across requests, not load it each time.
  • 它需要跨请求维护这些数据,而不是每次都加载它。

  • It needs to process multiple requests simultaneously.
  • 它需要同时处理多个请求。

  • It needs to be as configurable as possible regarding endpoints.
  • 它需要尽可能地配置端点。

  • It will be calling native dlls quite a lot.
  • 它会调用原生dll很多。

I suspect hosting it in IIS would simplify certain things, but I'm not sure it would be a good idea in this situation.

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

What are my options, and what are their pros and cons?

我有什么选择,他们的利弊是什么?

4 个解决方案

#1


16  

You need to basically look at three options:

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

1) Hosting in IIS6 (Windows Server 2003/2003 R2): in this scenario, you can only host HTTP protocols - nothing else. This is quite a limitation in itself, you cannot use e.g. netTcp for Intranet scenarios.

1)在IIS6中托管(Windows Server 2003/2003 R2):在这种情况下,您只能托管HTTP协议 - 没有别的。这本身就是一个很大的限制,你不能使用,例如netTcp for Intranet场景。

2) Hosting in IIS7 / WAS (Vista, Server 2008): this gives you more option in terms of protocols supported, and the hosting environment looks like a winner at first.

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

3) Self-hosting: in this scenario, it's totally up to you to do whatever you need to do to host and run your services.

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

If you throw out option #1 for now (if you only have IIS6 available, I'd always use self-hosting), it's down to IIS7 vs. self-hosting.

如果你现在抛出选项#1(如果你只有IIS6可用,我总是使用自托管),那就是IIS7与自托管。

IIS7 gives you "activation on demand", e.g. your service code is not in memory at all times, but will be loaded and instantiated once a request comes in. That can be a plus.

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

On the other hand, hosting in IIS7/WAS robs you of the ability to specify your own endpoints - your endpoint and thus service address is the virtual directory where your "MyService.svc" file lives - period. You cannot change that in any way, shape or form.

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

Self-hosting might look like a lot of work - but it does give you the best flexibility: you can pick your protocols as you like, you can set up your own addressing scheme the way you like it, and you have total control over what gets done when. You can introduce your own custom ServiceHost if you need to do some extra work to host services, and so on.

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

Unless you're just playing around with WCF a bit, I would always recommend and vote for self-hosting - if you need to have the WCF service running at all times, inside a Windows NT Service (that's the best solution for production environments), and if you're developing/debugging, you can totally host your WCF services in a console app which you can launch and stop at your leisure.

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

So to make a long story short: in the end, if you really want control over what's happening, I would always recommend self-hosting.

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

This might change once the new "Dublin" Server-Addon by Microsoft comes out - sometime after .NET 4 is launched, probably early in 2010 - but that's still too early to tell.

一旦微软推出了新的“都柏林”服务器 - 插件 - 可能会在.NET 4推出后的某个时间,可能是在2010年初 - 这可能会改变,但现在还为时尚早。

Hope this helps.

希望这可以帮助。

Marc

#2


6  

I prefer self hosted services myself (Windows service). With that said there are valid reasons for going either way.

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

There are some valuable articles in MSDN regarding different WCF hosting strategies.

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

Here is a good summary of why you might choose to use IIS as your service host.

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

#3


3  

I would say that without IIS7 and WAS you cannot host anything but HTTP based endpoints using IIS. As such you would most likely want to self host for flexibility.

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

As for your data considerations, any service can be coded with state such that data is cached etc.

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

Multiple requests will require you to use WCF concurrency. You want to set attributes on your service host:

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

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

WCF is a big beast, I recommend you have a look at Juval Lowy's book and anything else you can get your hands on, you will not learn it in a day.

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

#4


1  

Maybe a bit off topic but it does address consideration four.

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

If you end up going with self hosting and need to be as "configurable as possible regarding endpoints" you might want to take a look at Managed Services Engine. MSE is an open source product created by Microsoft Services that lets you virtualize your services. Basically, it is a WCF host that uses metadata from its own repository to expose services. Some features are: support of side by side versioning of services, ability to enable/disable operations on services, ability to map operations to endpoints, ability to apply policies to operations.

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

I'm not sure if it fits your needs but it's worth taking a look at -- especially if you need to be extremely configurable.

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

#1


16  

You need to basically look at three options:

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

1) Hosting in IIS6 (Windows Server 2003/2003 R2): in this scenario, you can only host HTTP protocols - nothing else. This is quite a limitation in itself, you cannot use e.g. netTcp for Intranet scenarios.

1)在IIS6中托管(Windows Server 2003/2003 R2):在这种情况下,您只能托管HTTP协议 - 没有别的。这本身就是一个很大的限制,你不能使用,例如netTcp for Intranet场景。

2) Hosting in IIS7 / WAS (Vista, Server 2008): this gives you more option in terms of protocols supported, and the hosting environment looks like a winner at first.

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

3) Self-hosting: in this scenario, it's totally up to you to do whatever you need to do to host and run your services.

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

If you throw out option #1 for now (if you only have IIS6 available, I'd always use self-hosting), it's down to IIS7 vs. self-hosting.

如果你现在抛出选项#1(如果你只有IIS6可用,我总是使用自托管),那就是IIS7与自托管。

IIS7 gives you "activation on demand", e.g. your service code is not in memory at all times, but will be loaded and instantiated once a request comes in. That can be a plus.

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

On the other hand, hosting in IIS7/WAS robs you of the ability to specify your own endpoints - your endpoint and thus service address is the virtual directory where your "MyService.svc" file lives - period. You cannot change that in any way, shape or form.

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

Self-hosting might look like a lot of work - but it does give you the best flexibility: you can pick your protocols as you like, you can set up your own addressing scheme the way you like it, and you have total control over what gets done when. You can introduce your own custom ServiceHost if you need to do some extra work to host services, and so on.

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

Unless you're just playing around with WCF a bit, I would always recommend and vote for self-hosting - if you need to have the WCF service running at all times, inside a Windows NT Service (that's the best solution for production environments), and if you're developing/debugging, you can totally host your WCF services in a console app which you can launch and stop at your leisure.

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

So to make a long story short: in the end, if you really want control over what's happening, I would always recommend self-hosting.

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

This might change once the new "Dublin" Server-Addon by Microsoft comes out - sometime after .NET 4 is launched, probably early in 2010 - but that's still too early to tell.

一旦微软推出了新的“都柏林”服务器 - 插件 - 可能会在.NET 4推出后的某个时间,可能是在2010年初 - 这可能会改变,但现在还为时尚早。

Hope this helps.

希望这可以帮助。

Marc

#2


6  

I prefer self hosted services myself (Windows service). With that said there are valid reasons for going either way.

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

There are some valuable articles in MSDN regarding different WCF hosting strategies.

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

Here is a good summary of why you might choose to use IIS as your service host.

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

#3


3  

I would say that without IIS7 and WAS you cannot host anything but HTTP based endpoints using IIS. As such you would most likely want to self host for flexibility.

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

As for your data considerations, any service can be coded with state such that data is cached etc.

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

Multiple requests will require you to use WCF concurrency. You want to set attributes on your service host:

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

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

WCF is a big beast, I recommend you have a look at Juval Lowy's book and anything else you can get your hands on, you will not learn it in a day.

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

#4


1  

Maybe a bit off topic but it does address consideration four.

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

If you end up going with self hosting and need to be as "configurable as possible regarding endpoints" you might want to take a look at Managed Services Engine. MSE is an open source product created by Microsoft Services that lets you virtualize your services. Basically, it is a WCF host that uses metadata from its own repository to expose services. Some features are: support of side by side versioning of services, ability to enable/disable operations on services, ability to map operations to endpoints, ability to apply policies to operations.

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

I'm not sure if it fits your needs but it's worth taking a look at -- especially if you need to be extremely configurable.

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