NService Bus - 获取队列上的所有待处理消息
我有一个应用程序通过 WCF 从许多其他应用程序接收数据。
我现在有一些客户也希望收到该数据的副本，但不同的客户有不同的需求。
- 客户 A 希望我们调用 Web 服务向他发送数据
- 客户 B 希望我们通过电子邮件向他发送数据
- 客户 C 希望建立自己的系统，该系统将轮询我提供的 Web 服务以接收他的数据。
我想使用 NServiceBus 已经有一段时间了，看起来这是一个很好的应用程序。我认为我可以通过设置端点以他们所需的格式/协议向他们提供数据来很好地处理客户 A 和 B。但客户C，我很挣扎。
我在 NService 总线中看到的所有示例都涉及订阅队列并在消息传入时触发事件。我想我在这里要做的是当客户调用他的数据时，我会抓取所有消息为他排队并交付它们。
我的问题是，这是 NServiceBus 的正确应用还是该工作的错误工具？如果是这样，是否有任何代码示例可以告诉我如何处理客户 C？
I have an application which receives data from a number of other applications via WCF.
I now have customers which would also like to receive copies of that data, but different customers have different needs.
- Customer A would like for us to call a web service to send him data
- Customer B would like for us to Email him with the data
- Customer C would like to set up his own system which will poll a web service that I provide to receive his data.
I've been wanting to use NServiceBus for quite a while, and it seems like this is a good application. I think I can handle Customer A and B just fine by setting up endpoints to deliver the data to them in their desired format/protocol. Customer C though, I'm struggling.
All of the samples I've seen in NService bus involve subscribing to a queue and firing an event when messages come in. I think what I want to do here is when the customer makes the call for his data, I would grab all the messages on the queue for him and deliver them.
My question is, is this a proper application of NServiceBus or is this the wrong tool for the job? If so, Are there any code samples out there that might show me how to handle customer C?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个很好的问题，因为它切中了基于消息的系统（特别是 NServiceBus）如何解决许多难题的核心问题。
您肯定朝着 A 和 B 的正确方向前进——只需订阅适当的消息，然后使用客户选择的机制将数据转发/推送给客户即可。如果它们离线，也没什么大不了的，基于消息的系统比其他系统更优雅地处理故障。
有趣的是，客户 C 的服务方式几乎与 A 和 B 完全相同，但有一些额外的步骤。首先，只需设置另一个 NSB 端点，该端点订阅相应的消息，然后使用客户 C 指定的所需结构将它们写入持久存储。您可以将消息写入本地数据库、JSON 文件，甚至 Amazon S3 斑点。从那里，您只需要设置某种 HTTP 端点（不使用 NServiceBus），允许客户查询和检索适当的数据。如果您使用 S3 并发出 JSON blob，您甚至可能不需要设置 HTTP 服务器 - 只需让 Amazon 完成所有工作即可。
另一个非常酷的副作用是，如果未来的客户 D 和 E 决定也想要进行轮询，但他们需要彼此之间以及客户 C 略有不同的格式，您可以通过设置另一个写出文件的处理程序来适应它们（或数据库插入）根据它们规定的格式 - 所有这些都不会改变您的系统的行为方式。
This is a great question because it cuts right to the heart of how message-based systems--and specifically how NServiceBus--can solve a lot of pain.
You're definitely headed in the right direction for A and B--just subscribe to the appropriate message and then forward/push the data to your customer using the mechanism that they've chosen. If they're offline, no big deal, the message-based system handles failures more gracefully than others.
Interestingly enough, customer C can be served in almost exactly the same way as A and B, but with a few extra steps. To start, just setup another NSB endpoint that subscribes to the appropriate messages and then writes them out to persistent storage using the desired structure indicated by customer C. You can write the messages out to a local database, to JSON files, or even to Amazon S3 blobs. From there you just need to setup some kind of HTTP endpoint (not using NServiceBus) that allows the customer to query and retrieve the appropriate data. If you're using S3 and giving out JSON blobs, you may not even need to setup an HTTP server--just let Amazon do all the work.
Another really cool side effect of this is that if future customers D and E decide they want to poll as well, but they need slightly different formats from each other and from customer C, you can accommodate them by setting up another handler that writes out files (or DB inserts) according to the format they dictate--all without changing how your system behaves.
可以通过 WCF 公开端点，但该端点用于将消息发送到总线上。如果有人想要轮询某个服务，我会单独托管该服务，并让他们在调用时进行管理。
It is possible to expose an endpoint via WCF, but that is used for getting messages onto the bus. If someone wants to poll a service, I would host that separately and let them manage when it gets called.