Windows 上无 UI 进程的最佳主机
我们正在计划一个在 Windows/.Net 3.5 上运行的系统，该系统有许多需要在后台运行的“服务”。 有些会一直活跃，但有些只会偶尔被调用，并且可以根据需要站立。
据我所知，我的选择是：
- Windows 服务 - 始终运行（？）
- IIS 托管某些东西 - 称为按需
- COM+/ .Net 企业服务 - 最复杂的选项，但最强大？
分布式事务不是必需的，这些主要是计算引擎，而不是事务处理器。
有谁有使用所有这些的经验以及进一步的优点和优点吗？ 每种技术都可以声明其缺点吗？
编辑
是否假设有多种方式在 IIS、Web 服务、WCF（如下所述）或其他方式中托管代码？ 相对优点/缺点？
We're planning a system running on Windows/.Net 3.5 that has a number of "services" that need to run in the background. Some will be active all of the time, but some will only be called occassionally and can be stood-up on demand.
As far as I can see, my options are:
- Windows Services - always running(?)
- IIS hosted something - called on demand
- COM+/ .Net Enterprise Sevices - most complex option, but most powerful?
Distributed transactions is not a requirement, these are mainly computation engines, rather than transaction processors.
Does anyone have any experience of working with all of these and what further pros & cons can be claimed for each technology?
EDIT
Is suppose there are multiple ways of hosting code in IIS, web services, WCF (as pointed out below), any others? Relative pros/cons?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
WCF 感觉是正确的选择。 还有很多选择要做。 WCF 提供了多种通信机制和托管环境：
WCF 在一组 API 下结合了以下技术 -
ASMX；
华尔街英语；
远程处理；
通讯+；
MSMQ。
例如，您可以将来自 MSMQ 的持久消息用于偶尔连接的客户端，或者通过 HTTP 传输层使用标准 XML 编码 SOAP 消息。 您还可以使用 3.5 中的新功能，例如 XML 的二进制编码或通过 HTTP 的 JSON 编码。
托管环境包括：
控制台应用程序
Windows 服务
IIS 7.0 内的 WCF 服务
在 Windows Vista 或 Windows Server 2008 上，您可以使用 WAS（Windows 激活服务）来托管 WCF 服务。
不同的托管环境各有利弊。 我建议您查看 MSDN 了解更多详细信息（例如 http://msdn.microsoft .com/en-us/library/bb332338.aspx）。
由于 WCF 包含大量功能，因此它比它所取代的任何一种技术都更难学习。 我仍然认为从长远来看它是值得的。
WCF feels like the right way to go. There are still many choices to make. WCF provides a number of communication mechanisms and hosting environments:
WCF combines the following technologies under one set of APIs-
ASMX;
WSE;
Remoting;
COM+;
MSMQ.
So for instance you can use persistent messages from MSMQ for occassionaly connected clients or standard XML encoding SOAP messages over an HTTP transport layer. You can also use new features in 3.5 like binary encoding of XML or JSON encoding over HTTP.
Hosting environments include:
Console applications
Windows services
WCF services inside IIS 7.0
and on Windows Vista or Windows Server 2008 you can use WAS (Windows Activation Services) to host WCF services.
Different hosting environments have pros and cons. I suggest you look at MSDN for more details (e.g. http://msdn.microsoft.com/en-us/library/bb332338.aspx).
Because WCF encompasses a lot of functionality it is more difficult to learn than any one of the technologies it replaces. I still think it pays for itself in the long run.
这取决于软件将做什么，以及用户或系统如何（以及是否）需要与其交互。 根据这些情况，可能还有一个经常被忽视的选项：将其设置为计划任务。 这通常是 Windows 服务的一个非常好的替代方案，如果该软件是那种按特定时间间隔运行的软件（例如，检查数据库中的更改，对更改的数据进行操作并将其发送到某个地方）。
如果您有其他系统直接与您的软件对话，我认为托管在 IIS 中的 WCF 应用程序将是一种相当直接的方式。 我们在我当前的任务中使用了这两种方法； 用于查找和存储数据的 WCF 服务，以及用于定期运行的数据计算的计划任务。
与某一特定领域的其他任务相比，计划任务有一个优点： 它仅在运行时使用系统资源。
It depends on what the software will do, and how (and if) users or systems need to interact with it. Depending on those things, there may be one more, often overlooked, option: set it up as a scheduled task. This is often a very good alternative to a windows service, if the software is of the kind that will act on certain time intervals (check for a change in a database, act on the changed data and send it somewhere, for instance).
If you will have other systems talking directly to your software, I would imagine that a WCF application hosted in IIS would be a rather straighforward way. We use both those approaches in my current assignment; WCF services for looking up and storing data, and scheduled tasks for data calculations that run on a regular basis.
The scheduled task has one upside compared to the others in one specific field; it uses system resources only when running.
您提到“按需”启动一个流程。 WAS - Windows 激活服务，有时也称为 Windows 进程激活服务，尽管它从来没有缩写为“WPAS” - 是 Windows 内部提供按需进程激活的东西。 它的工作方式是——当消息到达时，WAS 可以启动一个工作进程来处理该消息。 在 IIS7 之前，WAS 已相当紧密地集成到 IIS 中。 它主要用于激活执行 Web 工作的进程 - 例如 ASP.NET 工作进程。 在 IIS7 中，WAS 得到了通用化，因此它可以基于非 HTTP 和 HTTP 消息激活工作进程。 如果您编写应用程序来通过 WCF 接收消息，则基本上可以“免费”获得激活。 如果是 HTTP、TCP、MSMQ，则适用； SOAP 或其他。
不过，这种按需启动的关键在于它与通信息息相关。 事实上，WAS 的流程生命周期模型也与通信相关。 默认情况下，如果一段时间后没有传入消息，WAS 将关闭该进程。 这可能是也可能不是您想要的。
至于进程托管 - COM+ 提供了一个托管环境，但它主要用作通信进程的主机。 这可能不适合您。
如果您有计算引擎，您可能只想运行 Windows 服务。 类似的服务可以通过管理或编程方式启动和停止。 在后一种情况下，您可以想象一个 WAS 激活的工作进程以编程方式启动 Windows 服务。
您还可以想象编写一个简单的 Windows 服务来监视消息的位置（文件系统、消息队列等），当该文件或消息到达时，Windows 服务启动一个计算引擎进程，该进程本身不是 Windows 服务，但只是一个过程。
说到 MSMQ - 这基本上与 MSMQ 触发器相同的模型。 您可以将 MSMQ 配置为在消息到达特定队列时启动进程。
有很多选择。
You mentioned starting up a process "on demand". WAS - Windows Activation Service, or sometimes called Windows Process Activation Servvice, though it is never abbreviated "WPAS" - is the thing inside Windows that provides on-demand process activation. The way it works - when a message arrives, WAS can start a worker process to handle the message. WAS was, prior to IIS7, fairly tightly integrated into IIS. It was used primarily to activate processes that did web work - like an ASP.NET worker process. With IIS7, WAS is generalized so that it can activate worker processes based on non-HTTP as well as HTTP messages. If you write your app to receive messages through WCF, you can get activation essentially "for free". That applies if it is HTTP, TCP, MSMQ; SOAP or otherwise.
The key thing with this on-demand startup though, is that it is tied to the communication. In fact the process lifecycle model for WAS is tied to communication as well. By default if there are no incoming messages after a while, the process will be shut down by WAS. That may or may not be what you want.
As for process hosting - COM+ offers a hosting environment but it is primarily intended for use as a host for processes that communicate. This may not be the perfect fit for you.
If you have compute engines, you may just want to run a Windows Service. A service like that can be started and stopped either administratively or programmatically. In the latter case, you could imagine a WAS-activated worker process programmatically starting a windows service.
You could also imagine writing a simple Windows Service that watches a location (filesystem, message queue, etc) for a message, and when that file or message arrives, the Windows Service starts up a compute engine process, which itself is NOT a Windows Service, but is just a process.
Speaking of MSMQ - That is basically the same model as MSMQ triggers. You can configure MSMQ to start a process when a message arrives on a particular queue.
There are lots of options.