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调用来轮询我们的本地主机 WCF服务。

2.2选项甚至有可能吗？我们应该为WCF服务使用哪种绑定？跨域调用（从公共域到本地主机）有问题吗？

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

有几个其他替代方案可用于网络之间的通信应用程序和桌面应用程序（java插件，用于IE的active x，firefox插件，chrome原生插件，...），但对于新版本的浏览器，Java版本，Windows版本，它们都非常脆弱......您必须保持所有这些。我们正在寻找一种适用于所有主流浏览器的选项，并且负责Web应用程序的制造商将尽可能少地完成工作。

Answer 1

2.2选项甚至有可能吗？

Yes

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

1. 从Web应用程序的来电（HREF链接），你应该暴露你的服务操作的REST端点，使用WCF webHttpBinding或类似Nancy，这是轻得多。

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

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

根据您的描述，这似乎并没有成为一个真正的双向需求，如双工（呼叫会双向）。在这两种情况下，您概述了来自合作伙伴网站的呼叫。这只是以其他方式旅行的答案，还是我错过了一些东西？

轮询选项只是一个想法如何从桌面得到国家 应用到Web应用程序

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

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

对于你的合作伙伴来说，这可能不会有太多的工作，因为尽管他们需要为你打电话来主持一个新的“状态改变”端点，但ajax轮询任务可能会更简单，因为他们会轮询他们自己的服务，而不是你的。