Progress notification in WCF for long running processes - How?

Question

I have to design and implement a way to deal with long running processes in a client/server application. A typical long running process would/could take 2-3 minutes. I also need to report progress to the UI in the meantime and keep the UI responsive.

Having these in my mind I though of a few solutions:

• One async request to start the process which starts the server-side process and returns an assigned LRPID (Long Running Process ID) then poll periodically from the client using that LRPID. (Pro: simple to deploy, no firewall messing around Con: Unelegant, resource consuming etc.)

• Use a duplex binding (such as NetTcpBinding) and initiate callbacks from the server as progress is being made (Pro: Elegant, efficient, Con: Deployment nightmare)

• [Your suggestion???]

What would be your take on this?

Agc

What is the client side app written in? – Legality

Deployment nightmare? Why, because of IIS/WAS? Then don't use them. – Hoffer

@Daniel Auger: The client app is written in WPF – Affiliation

@Allon Guralnek: Because of opening ports in firewall, hosting the "miniserver" on the client ready for callbacks etc. – Affiliation

You'd have to do that with any WCF service. – Hoffer

Answer 1

Here is a post by Dan Wahlin about how to create a WCF Progress Indicator for a Silverlight Application. This should be of some help.

Antibaryon

looks pretty cool, I'll have to look a little more into it. Thanks! – Affiliation

Ok, this proved to be the best middle way! Especially because "... It initiates a network request, and then the request is effectively “put to sleep” waiting for the server to respond (it doesn’t come back immediately). The server then keeps the connection open but not active until it has something to send back (or the connection times out after 90 seconds – at which point the duplex client will connect again and wait). This way you are avoiding hitting the server repeatedly – but still get an immediate response when there is data to send." – Affiliation

or in other words, an already-implemented, light-weight-and-effective polling system that simulates a true-two-way version – Affiliation

Answer 2

If you do not want to have to worry about the client's firewall, etc... I would probably go with your first solution and use a BackGroundWorker to make the call in order to keep from blocking the UI thread. I did this recently for an app where a request to generate a report is put on a queue and is retrieved once it is done. It seems to work well.

Legality

Answer 3

Another way (without having to change the WCF binding) is to use a WebBrowser control in the WPF client, and SignalR to post progress messages from the server to that control.

Note that to avoid javascript errors that happen with the WebBrowser control (because by default it seems to use Internet Explorer version 7 which doesn't seem to be compatible with jQuery.js), you will need to add keys to the registry on the client machine to change the default for the client app to use IE10 or later - see http://weblog.west-wind.com/posts/2011/May/21/Web-Browser-Control-Specifying-the-IE-Version). This could be a deployment nuisance (because admin rights seem to be needed - eg on a 64 bit Windows 8.1 pc - to add the registry keys). Also, it still seems necessary to call the long running WCF method in a separate thread, otherwise the WebBrowser control doesn't seem to update its display to show the SignalR messages it is receiving. (This makes sense because the UI thread would otherwise have to wait until the WCF call had finished).

But I mention it as an alternative approach using a newer tool (SignalR) :)

Microfarad