异步调用和响应(web-services)之间的最大时间

Question

是否有任何最佳实践规定异步调用与其相应响应之间的最长时间。

基本上，我有一个需要很长时间才能运行的过程(例如:5分钟)。选项1: I可以将进程公开为异步调用。在这种情况下，用户调用我的服务，然后在以后的某个时候，我用进程状态进行响应。

选项2我可以实现的另一种方式是设置系统，以便在我的web服务上有一个单向操作，它开始进程并立即返回进程的id。然后，我可以要求使用者提供一个单向操作，当流程完成时，我可以打电话并报告。

第一种选择比较容易，因为我不需要强制调用者做任何事情。第二个似乎更好，因为我可以在任何时候(5分钟到几年后)报告。

由于我完全控制了调用者及其内部可用的服务，所以我倾向于选择2。

因此，我想知道异步调用是否有任何时间限制(它们能跨越几天吗？)如果不是最好的做法是什么)。备选方案2是否采用标准模式？

参考资料将非常有用。

Answer 1

选项2是更好的，因为它更多的事件驱动。

但是，存在一个选项#3.客户端向服务器发出请求。服务器队列请求并使用id进行响应。客户端每隔一次检查一次，传递请求id，以查看它是否已经完成。

这样，您就不必依赖于请求完成时客户端是否可用。

我可能会将选项#2和#3混合在一起，让客户端选择是希望在自己的一侧触发事件，还是只希望稍后再检查。

更新

Rajah询问了异步请求和响应之间的最长时间。对于WEB应用程序，这通常是以秒为单位的。大多数服务器的超时值通常在30秒范围内默认。就我个人而言，我认为这太长了。

考虑到异步调用要求客户端和服务器之间的通信通道在持续时间内处于打开状态。一个服务器可以处理多少个这些通道？更重要的是，当您提出请求时，您需要维护多少个频道？即使你控制了两端，这也会变得相当离谱。

不管您的服务托管的是什么，都将决定保持请求打开的最大时间。同样，我看到的每一台服务器都会在几秒钟内测量这一点。