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

Question

I am curious if this scenario is even possible:

1. .Net Windows Forms application (our product) with a couple of WCF services exposed (self hosted, for example on ' http://localhost:8000/myservice/method1 '), running in elevated mode.
2. A web application (from another manufacturer) on a public domain, which would communicate with our application in a two-way mode:
   1. web application to desktop application: during the setup of our application we register a custom protocol 'xxx' (similar to 'mailto') and set our application as a handler for this protocol. So the web application can trigger an action in our desktop application with links in the form 'href="xxx:parameters"'.
   2. desktop application to web application: the web application would periodically (every second for example) poll our localhost WCF services via javascript ajax calls.

Is the 2.2 option even possible? Which binding should we use for WCF services? Are there any problems with cross domain calls (from public domain to localhost)?

Edit - yes, the communication is not two-way because in our scenario the desktop application cannot directly manipulate the web application. The polling option is just an idea how to get state from desktop application to web application, so if there are better alternatives I would very much like to hear about it :)

There are a couple of other alternatives for communication between web application and desktop application (java plugins, active x for IE, firefox plugins, chrome native plugin,...) but they are very fragile regarding new versions of browsers, versions of java, version of Windows,... and you have to maintain all of them. We are looking for a option which would work on all major browsers and that the manufacturer, which is responsible for web application, would have as little work as possible.

Answer 1

Is the 2.2 option even possible?

Yes

Which binding should we use for WCF services?

1. For the incoming calls from the web app (href links) you should expose your service operation as a REST endpoint, using WCF webHttpBinding or something like Nancy , which is much lighter.

2. For the polling, as already mentioned, you need to host another REST endpoint.

Two-way communication between web application and desktop application

Based on your description, this doesn't appear to be a genuine two-way requirement, as in duplex (calls going both ways). In both scenarios you outline the calls originate on the partner website. It's only the responses which travel the other way, or am I missing something?

The polling option is just an idea how to get state from desktop application to web application

Strictly speaking, the polling originator is not the web app per se , but the client browser via JavaScript. Apart from any architectural concerns of using a client app as an intermediary between desktop and server, there is a very real complication around implementing cross-origin scripting in the browser.

I suggest a better solution would be to call the web app from the desktop app when state changes, and then have the web app "notify" the web client, either via ajax polling (to the web app), or something like SignalR .

This would likely be not much more work for your partner as although they would need to host a new "Status Changed" endpoint for you to call, the ajax polling task would probably be simpler seeing as they'd be polling their own service rather than yours.