推荐的用于发布客户端事件的消息总线架构
对于以下场景，推荐的消息传递体系结构是什么：
- 运行 WinForms 客户端的多个工作站
- 客户端必须可靠地将事件通知两个（或多个）Windows 服务
最初，我们希望避免在客户端工作站上配置 MSMQ，因此我们创建了一个 Web 服务。事实证明这很难配置，然后我读到从 Web 应用程序发布 NServiceBus 消息是 不推荐。
最佳实践是：
- 让客户端调用 Web 服务，该服务将消息发送（而不是发布）到 Windows 服务，后者发布该消息？
- 将消息直接从客户端应用程序发送（而不是发布）到服务器上的远程队列，Windows 服务从该队列发布消息？
- 其他？
目前我正在尝试使用 NServiceBus 来实现这一点，但希望答案与总线无关。
编辑：
如果客户端只是发送（而不是发布）到远程队列，是否需要在客户端工作站上配置（甚至安装）MSMQ？在这种情况下，如果远程队列无法访问会发生什么？
What's the recommended messaging architecture for the following scenario:
- Multiple workstations running a WinForms client
- Clients must reliably notify two (or more) Windows Services of an event
Initially we wanted to avoid configuring MSMQ on the client workstations, so we created a web service. This proved difficult to configure, and then I read that publishing NServiceBus messages from a web application is not recommended.
Is the best practice to:
- Have the clients call a web service, which sends (not publishes) a message to a Windows service, which publishes the message?
- Send (not publish) the message directly from the client applications to a remote queue on a server, from which a Windows service publishes the message?
- Other?
Currently I am trying to implement this using NServiceBus, but hopefully the answer is bus-agnostic.
Edit:
If clients simply send (not publish) to a remote queue, does MSMQ need to be configured (or even installed) on the client workstations? In that case what happens if the remote queue is unreachable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以将 NServiceBus 端点公开为 WCF 服务。
从 NServiceBus 和 WCF 页面的底部：
看一下。您应该能够让客户端应用程序连接到 WCF 服务以删除消息。您可以使用 http、net.tcp 或任何适合您的 WCF 传输来配置 WCF 服务。
即使该服务使用 HTTP 传输（尽管您可能必须选择非标准端口），该服务也不会成为 Web 应用程序。它将是一个公开 Web 服务接口的 Windows 服务。从这里发布消息就可以了。这使您不必在所有客户端上配置 MSMQ，但仍然具有 NServiceBus 的便利性和灵活性。
当然，如果您关心该服务的可扩展性，您可能需要一个具有负载平衡功能的 IIS 托管 Web 服务。在这种情况下，创建一个普通的 WCF Web 服务，将消息发送到作为 Windows 服务安装的 NServiceBus.Host.exe 终结点，然后从该 Windows 服务发布事件。
You can expose an NServiceBus endpoint as a WCF service.
From the bottom of the NServiceBus and WCF page:
Take a look at that. You should be able to have your client applications connect to the WCF services to drop messages. You can configure the WCF service with http, net.tcp, or whatever WCF transport works for you.
This service would then NOT be a web application, even if it uses the HTTP transport (although you might have to pick a nonstandard port). It would be a Windows service exposing a web service interface. It would be fine to publish messages from here. This gives you the freedom from having to configure MSMQ on all the clients but still a lot of the NServiceBus ease and flexibility.
Of course if scalability of this service is a concern, you may want to have an IIS-hosted web service with load balancing. In that case, create a normal WCF web service that sends a message to a NServiceBus.Host.exe endpoint installed as a Windows service, and then publish events from that Windows service.
我认为客户端应该按照选项二的建议直接向服务器发送消息。尽管您必须在客户端工作站上配置 msmq。你为什么不想这样做？
这样做的好处是端到端的耐用性。
我注意到您谈论发送与发布，但是我在您的场景中看不到任何需要使用 NSB 发布-订阅的内容。
仅供参考，发送到远程队列并从本地队列读取几乎总是最好的。
I think the clients should message the servers directly as your option two suggests. Though you would have to configure msmq on the client workstations. Why do you not want to do this?
This has the benefit of durability end-to-end.
I notice you talk about sending vs publishing, however I can't see anything in your scenario which warrants using NSB pub-sub.
FYI it's almost always the best thing to send to remote queues and read from local queues.