0

我们正在计划一个在 Windows/.Net 3.5 上运行的系统，该系统具有许多需要在后台运行的“服务”。有些会一直处于活动状态，但有些只会偶尔被调用并且可以按需站立。

据我所知，我的选择是：

  • Windows 服务 - 始终运行（？）
  • IIS 托管了一些东西 - 按需调用
  • COM+/ .Net 企业服务 - 最复杂的选项，但最强大？

分布式事务不是必需的，这些主要是计算引擎，而不是事务处理器。

有没有人有使用所有这些技术的经验，以及每种技术的进一步利弊？

编辑

假设在 IIS、Web 服务、WCF（如下所述）中有多种托管代码的方式，还有其他方式吗？相对的优点/缺点？

4

3 回答 3

2

WCF 感觉是正确的方法。还有很多选择要做。WCF 提供了多种通信机制和托管环境： WCF 在一组 API 下结合了以下技术——ASMX；华尔街英语; 远程处理；通讯+；MSMQ。因此，例如，您可以将来自 MSMQ 的持久消息用于偶尔连接的客户端或通过 HTTP 传输层对 SOAP 消息进行标准 XML 编码。您还可以使用 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 包含很多功能，所以它比它所替代的任何一种技术都更难学习。从长远来看，我仍然认为它会为自己付出代价。

于 2009-07-13T16:23:58.323 回答
1

这取决于软件将做什么，以及用户或系统如何（以及是否）需要与之交互。根据这些情况，可能还有一个经常被忽视的选项：将其设置为计划任务。这通常是 Windows 服务的一个很好的替代方案，如果软件是那种会在特定时间间隔内起作用的软件（例如，检查数据库中的更改，对更改的数据进行操作并将其发送到某个地方）。

如果您将让其他系统直接与您的软件对话，我想托管在 IIS 中的 WCF 应用程序将是一种相当直接的方式。我们在我目前的任务中使用了这两种方法；用于查找和存储数据的 WCF 服务，以及用于定期运行的数据计算的计划任务。

与其他特定领域的其他任务相比，计划任务有一个优势；它仅在运行时使用系统资源。

于 2009-07-13T13:30:11.283 回答
1

您提到“按需”启动流程。WAS - Windows Activation Service，或有时称为 Windows Process Activation Servvice，尽管它从未缩写为“WPAS” - 是 Windows 内部提供按需进程激活的东西。它的工作方式——当消息到达时，WAS 可以启动一个工作进程来处理消息。在 IIS7 之前，WAS 已相当紧密地集成到 IIS 中。它主要用于激活执行 Web 工作的进程 - 例如 ASP.NET 工作进程。在 IIS7 中，WAS 被通用化，因此它可以激活基于非 HTTP 以及 HTTP 消息的工作进程。如果您编写应用程序以通过 WCF 接收消息，则基本上可以“免费”获得激活。如果是 HTTP、TCP、MSMQ，则适用；肥皂或其他。

不过，这种按需启动的关键在于它与通信相关。事实上，WAS 的流程生命周期模型也与通信相关联。默认情况下，如果一段时间后没有传入消息，则该进程将被 WAS 关闭。这可能是也可能不是你想要的。

至于进程托管 - COM+ 提供了一个托管环境，但它主要用作通信进程的主机。这可能不适合您。

如果您有计算引擎，您可能只想运行 Windows 服务。可以通过管理或编程方式启动和停止这样的服务。在后一种情况下，您可以想象一个 WAS 激活的工作进程以编程方式启动 Windows 服务。

您还可以想象编写一个简单的 Windows 服务来监视消息的位置（文件系统、消息队列等），当该文件或消息到达时，Windows 服务启动一个计算引擎进程，该进程本身不是 Windows 服务，但只是一个过程。

说到 MSMQ - 这与 MSMQ 触发器的模型基本相同。您可以将 MSMQ 配置为在消息到达特定队列时启动进程。

有很多选择。

于 2009-07-17T11:13:41.867 回答