Windows 服务到 Windows 应用程序和 Web 应用程序技术选项 - 优点和缺点

Question

我们目前正在实现一个 Windows 服务，该服务需要发布 Windows 或 Web 应用程序可以订阅的信息。发布的信息应主要由字符串组成，并将用于记录服务正在执行的任务，因此将有源源不断的信息流发送到订阅的应用程序。

我一直在研究诸如 MSMQ、WCF 和 ESB（如 Nservicebus）之类的技术，但由于我对使用 Windows 服务和应用程序订阅都非常陌生，因此到目前为止很难了解每个以及哪个（如果有）将是此类项目的理想选择。任何更熟悉这些选项的人都可以提供这些技术提供的一些优点/缺点吗？

为了更好地总结我之前的段落，该项目预计将在以下条件下运行：

1. 消息不断地从服务发布到任何订阅的应用程序
2. 预计通信是单向的（服务到应用程序），因此任何应用程序的停机时间都不应影响服务的工作
3. 服务必须同时发布到 Windows 应用程序和 Web 应用程序
4. 未来可能需要订阅新应用程序，而不会中断服务的工作（似乎是既定的，但正如我所说，我不熟悉这些选项）
5. 该程序的首选语言是 C#。

非常感谢您抽出宝贵时间，我们将不胜感激有关这些或更合适的技术的任何建议。

Answer 1

围绕 MSMQ 和 WCF 有很多选择。取决于许多因素，有几种不同的方法和框架可以提供帮助。

如果您想自己做一些指导，我建议您看看 Tom Hollanders 的精彩帖子：

http://blogs.msdn.com/b/tomholl/archive/2008/05/17/building-a-pub-sub-message-bus-with-wcf-and-msmq.aspx

http://blogs.msdn.com/b/tomholl/archive/2008/07/12/msmq-wcf-and-iis-getting-them-to-play-nice-part-1.aspx

如果您要使用现有的服务总线，例如 BizTalk、nServiceBus 或 MassTransit，还有其他更“完整”的选项。

另一个选项是多播，自 MSMQ 3.0 起就可以使用，这是一项支持将一个发布者（您的 windows 服务）到多个接收者（您的 windowsapp 和 webapp）的场景。发送方和接收方都可以使用 MsMqIntegration 绑定与队列交互。

建议你看看：http://blogs.msdn.com/b/solutions/archive/2005/09/20/471615.aspx