C# WCF、长时间运行的服务器操作和WinRT客户端

我目前面临一个问题：

• WCF服务公开了大量方法，其中一些方法可能需要更长的时间
• 客户端是WinRT（Metro样式）应用程序（因此某些.NET类不可用）
• 客户端上的超时已增加到1.5分钟
• 尽管超时时间增加了，但某些操作仍然需要更长的时间（但并非总是如此）
• 如果发生超时，服务将继续正常运行。请求的操作的结果丢失。更糟糕的是，如果操作成功，那么客户端将无法获得所需的数据，服务器也不会“回滚”

所有操作都已在客户端上使用

async

模式实现。我可以使用基于事件的实现，但据我所知，超时仍然会发生

增加超时值肯定是一个选项，但它感觉像是一个非常肮脏的解决方案——它感觉像是将问题推开而不是解决它

在服务器上实现WS-transaction流似乎是不可能的-在设计WinRT应用程序时，我无权访问

TransactionScope

类

WS-Atomic似乎也有些过分（它还需要更多的设置，我敢打赌WinRT应用程序的有限功能将是一个需要克服的大麻烦）

到目前为止，我唯一的想法（尽管有更多的运动部件，感觉像是重新发明轮子）是创建两种服务方法——一种是开始一些长期运行的操作并返回某种“任务ID”，然后在后台运行操作，并保存操作结果（无论是错误还是成功）然后，客户端可以每隔一段时间通过第二个服务方法使用该任务ID轮询操作结果，直到该结果可用为止（无论是成功还是错误）

这种方法也有其缺点：

• 由于客户端需要对结果进行轮询，长时间的操作会变得更长
• 大量新的活动部件，可能会使整个系统不太稳定

我还可以尝试什么来解决这个问题

另外，实际的服务端也不是没有限制的——它是一个MS DAX服务，可能有自己的一套潜在陷阱和陷阱

编辑：

---

看来我的问题和…有些相似。。。但是，考虑到客户端的WinRT特性和服务的MS DAX特性，我不确定答案中的任何内容对我是否真的有用。

如果操作完成，您可以向客户端进行4次回调。看看“双面”装订吧。。。但要注意它的重要性limitations@Cadburry在处理个人项目时，我曾经通过WCF/SL实现过一次双工绑定。首先，这并不容易（除非现在有一些现成的软件包可用），而且我相信WinRT类的限制集很可能是一个不可逾越的障碍。。。更不用说服务器端的潜在问题（由于服务的MS DAX性质）。实现并不困难，但DPB是MS的支柱。。因此，第三方客户端可能无法使用它。我不知道DAX的限制，所以你只需要给他们一个尝试；）。。我想这会管用的。如果操作完成，你可以回叫客户。看看“双面”装订吧。。。但要注意它的重要性limitations@Cadburry在处理个人项目时，我曾经通过WCF/SL实现过一次双工绑定。首先，这并不容易（除非现在有一些现成的软件包可用），而且我相信WinRT类的限制集很可能是一个不可逾越的障碍。。。更不用说服务器端的潜在问题（由于服务的MS DAX性质）。实现并不困难，但DPB是MS的支柱。。因此，第三方客户端可能无法使用它。我不知道DAX的限制，所以你只需要给他们一个尝试；）。。我想它会起作用的