Web应用程序和桌面应用程序之间的双向通信

Question

我很好奇这种情况是否可能：

1. .Net Windows窗体应用程序（我们的产品）暴露了几个WCF服务（自托管，例如在“http://localhost:8000/myservice/method1”上），以提升模式运行。
2. 公共域上的Web应用程序（来自其他制造商），它将以双向模式与我们的应用程序通信：
   1. Web应用程序到桌面应用程序：在我们的应用程序设置期间，我们注册了一个自定义协议'xxx'（类似于'mailto'）并将我们的应用程序设置为此协议的处理程序。因此，Web应用程序可以在我们的桌面应用程序中触发一个动作，其中包含“href =”xxx：parameters“'形式的链接。
   2. 桌面应用程序到Web应用程序：Web应用程序会定期（例如每秒）通过javascript ajax调用来轮询我们的 localhost WCF服务。

2.2选项是否可行？我们应该为WCF服务使用哪种绑定？跨域调用（从公共域到localhost）是否有任何问题？

编辑 - 是的，通信不是双向的，因为在我们的场景中，桌面应用程序无法直接操作Web应用程序。轮询选项只是一个如何从桌面应用程序获取状态到Web应用程序的想法，所以如果有更好的选择，我非常希望听到它：）

Web应用程序和桌面应用程序之间的通信还有其他几种选择（java插件，IE的活动x，firefox插件，chrome本机插件......）但是对于新版本的浏览器，版本非常脆弱java的版本，Windows的版本，......你必须维护所有这些。我们正在寻找适用于所有主流浏览器的选项，并且负责Web应用程序的制造商将尽可能少地工作。

Answer 1

  

2.2选项是否可能？

Yes

  

我们应该为WCF服务使用哪种绑定？

1. 对于来自Web应用程序（href链接）的传入呼叫，您应该使用WCF webHttpBinding或类似Nancy之类的东西将您的服务操作公开为REST端点。

2. 对于轮询，如前所述，您需要托管另一个REST端点。

  

Web应用程序和桌面应用程序之间的双向通信

根据您的描述，这似乎不是真正的双向要求，如双工（双向呼叫）。在这两种方案中，您都会概述来自合作伙伴网站的呼叫。只有那些以另一种方式旅行的回应，或者我错过了什么？

  

轮询选项只是一个如何从桌面获取状态的想法   应用程序到Web应用程序

严格来说，轮询发起人不是网络应用本身，而是客户端浏览器通过JavaScript。除了使用客户端应用程序作为桌面和服务器之间的中介的任何架构问题之外，在浏览器中实现cross-origin scripting还有一个非常复杂的问题。

我建议更好的解决方案是在状态发生变化时从桌面应用程序调用Web应用程序，然后通过ajax轮询（到Web应用程序）或{{让Web应用程序“通知”Web客户端3}}。

这可能对您的合作伙伴来说不会有太多工作，因为虽然他们需要托管一个新的“Status Changed”端点供您调用，但是ajax轮询任务可能会更简单，因为他们正在轮询他们自己的服务而不是你的。