网络服务背后的工作进程......使用什么成分
我有以下秘诀：Web 服务 (SOAP) 需要能够在短时间内接收大量请求。它们应该排队等待异步处理。因此，在后台，应该有一个工作人员从队列中获取请求并对其进行处理。有些作业甚至可能遇到不可用的（第三方）资源，在这种情况下，应稍后重试该作业。
我的问题是：我的成分是什么？ WCF、MSMQ、WAS？设置这个的基本结构是什么？
I have the following recipe: a web-service (SOAP) needs to be able to receive a lot of requests in a short time. They should be queued for asynchronous processing. So in the background, there should be a worker that takes the requests from the queue and does a job on them. Some of the jobs may even encounter unavailable (third party) resources, in which case the job should be retried later.
The question I have is: what are my ingredients? WCF, MSMQ, WAS? What is the basic structure of setting this up?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为是否将它们存储在 MSMQ、SQL 或其他地方并不重要 - 您选择的任何后备存储都需要额外的服务来使数据出列和处理。与纯 MSMQ 相比，SQL 数据库可能具有一些优势，例如，您可以使用数据存储一些附加信息，然后随时间检索一些统计信息、处理了多少个请求以及它们的内部结构是什么。这可以帮助您将来进一步调整处理管道。
I don't think it's important whether you'll store them, in MSMQ or in SQL or somewhere else - any backstore you choose will require an additional service to dequeue and process the data. A SQL database could have some advantages over pure MSMQ, for example you could store some additional information with your data and then retrieve some statistics over time, how many requests were processed and what was their internal structure. This could help you in future to further tune the processing pipeline.