http接口适合长时间运行
我有一个正在运行的系统，它使用基于 Agatha-RRSL 的请求-响应接口来处理短期和长期运行的操作。
现在我们想要进行一些更改，以便能够通过网站以 Json 格式发送请求，因此我正在尝试许多支持 Json 的 REST 服务器实现。 REST 服务器将是由 Topshelf 处理的一个模块或“搁置”，另一个模块将是处理模块，最后一个是 NoSQL 数据库运行器模块。
为了在 REST 和处理模块之间进行讨论，我正在考虑 servicebus，但我们有两种类型的请求：在 1-2 秒内执行工作的短请求和在 1 分钟内执行工作的长请求。servicebus
是正确的选择吗？工作？我正在考虑使用令牌返回长时间运行的操作的“响应”，该令牌可用于通过新请求请求操作状态和结果。问题是大部分请求必须像同步请求一样使用才能完成http响应。
我想当我必须返回大量对象时，我也遇到响应大小（在 MSMQ 消息传输上）的问题
有任何提示吗？
I have a running system that process short and long running operations with a Request-Response interface based on Agatha-RRSL.
Now we want to change a little in order to be able to send requests via website in Json format so i'm trying many REST server implementation that support Json.
REST server will be one module or "shelve" handled by Topshelf, another module will be the processing module and the last the NoSQL database runner module.
To talk between REST and processing module i'm thinking about a servicebus but we have two types of request: short requests that perform work in 1-2 seconds and long requests that do work in 1 minute..
Is servicebus the right choice for this work? I'm thinking about returning a "response" for long running op with a token that can be used to request operation status and results with a new request. The problem is that big part of the requests must be used like sync request in order to complete http response.
I think I have also problems with response size (on MSMQ message transport) when I have to return huge list of objects
Any hint?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
NServiceBus 并不真正适合请求-响应消息传递模式。它更适合异步发布订阅。
编辑：为了实现一种请求响应，您需要双向发送消息，但包含三个逻辑步骤：
由于每个步骤都是以异步方式隔离进行的，因此在客户端发送请求和接收响应之间不会强制执行任何有意义的 SLA 或超时。但这对于可能需要几分钟才能完成的大型处理作业非常有效。
此外，两个消息中都需要存在可用于将请求与响应联系起来的通用值。否则，客户端可能会发送多个请求，并收到多个响应，并且不知道哪个响应针对哪个请求。
因此，您可以使用 NServiceBus 来完成此操作，但需要多考虑一下。
此外，NServiceBus 使用 MSMQ 作为底层传输，而不是 http。
NServiceBus is not really suitable for request-response messaging patterns. It's more suited to asynchronous publish-subscribe.
Edit: In order to implement a kind of request response, you would need to message in both directions, but consisting of three logical steps:
Because each of these steps takes place in isolation and in an asynchronous manner there can be no meaningful SLA or timeout enforced between when a client sends a request and receives a response. But this works nicely for large processing job which may take several minutes to complete.
Additionally a common value which can be used to tie the request to the response will need to be present in both messages. Otherwise a client could send more than one request, and receive multiple responses and not know which response was for which request.
So you can do this with NServiceBus but it takes a little more thought.
Also NServiceBus uses MSMQ as the underlying transport, not http.