WCF Windows Service - Long operations/Callback to calling module

Question

I have a Windows Service that takes the name of a bunch of files and do operations on them (zip/unzip, updating db etc). The operations can take time depending on size and number of files sent to the service.

(1) The module that is sending a request to this service waits until the files are processed. I want to know if there is a way to provide a callback in the service that will notify the calling module when it is finished processing the files. Please note that multiple modules can call the service at a time to process files so the service will need to provide some kind of a TaskId I guess.

(2) If a service method is called and is running and another call is made to the same service, then how will that call be processed(I think there is only one thread asociated with the service). I have seen that when the service is taking time in processing a method, the threads associated with the service begin to increase.

Answer 1

WCF does indeed offer duplex bindings which allow you to specify a callback contract, so that the service can call back to the calling client to notify.

However, in my opinion, this mechanism is rather flaky and not really to be recommended.

In such a case, when the call causes a fairly long running operation to happen, I would do something like this:

If you want to stick to HTTP/NetTcp bindings, I would:

• drop off the request with the service, and then "let go" - this would be a one-way call, you just drop off what you want to have done, and then your client is done
• have a status call that the client could call after a given time to find out whether or not the results of the request are ready by now
• if they are, there should be a third service call to retrieve the results

So in your case, you could drop off the request to zip some files. The service would go off and do its work and store the resulting ZIP in a temporary location. Then later on the client could check to see whether the ZIP is ready, and if so, retrieve it.

This works even better over a message queue (MSMQ) which is present in every Windows server machine (but not a lot of people seem to know about it or use it):

• your client drops off the request on a request queue
• the service listens on that request queue and fetches request after request and does it works
• the service can then post the results to a result queue, on which your callers in turn are listening

Check out how to do all of this efficiently by reading the excellent MSDN article Foudnations: Build a queue WCF Response Service - highly recommended!

A message-queue based systems tends to be much more stable and less error-prone that a duplex-/callback-contract based system, in my opinion.

Answer 2

(1) The simplest way to achieve this is with a taskId as you note, and then have another method called IsTaskComplete with which client can check whether the task has been completed.

(2) Additional calls made to the service will start new threads.

edit: the default service behaviour is to start new threads per call. The configurable property is Instance Context Mode, and can be set to PerCall, PerSession, or Shareable.

Answer 3

The question has a solution, but I'm using a WCF duplex service to get the result of a long operation, and even though I found a problem that has cost me several hours to solve (and that's why I searched this question earlier), now it works perfectly, and I believe it is a simple solution within the WCF duplex service framework.

What is the problem with a long operation? The main problem is blocking the client interface while the server performs the operation, and with the WCF duplex service we can use a call back to the client to avoid the blockage (It is an old method to avoid blocking but it can easily be transformed into the async/await framework using a TaskCompletionSource).

In short, the solution uses a method to start the operation asynchronously on the server and returns immediately. When the results are ready, the server returns them by means of the client call back.

First, you have to follow any standard guide to create WCF duplex services and clients, and I found these two useful:

msdn duplex service

Codeproject Article WCF Duplex Service

Then follow these steps adding your own code:

1. Define the call back interface with an event manager method to send results from the server and receive them in the client.

   public interface ILongOperationCallBack
   { 
       [OperationContract(IsOneWay = true)]
       void OnResultsSend(....);        
   }
   

2. Define the Service Interface with a method to pass the parameters needed by the long operation (refer the previous ILongOperationCallBack interface in the CallBackContractAttribute)

   [ServiceContract(CallbackContract=typeof(ILongOperationCallBack))]
   public interface ILongOperationService
   {
       [OperationContract]
       bool StartLongOperation(...);
   }
   

3. In the Service class that implements the Service Interface, first get the proxy of the client call back and save it in a class field, then start the long operation work asynchronously and return the bool value immediately. When the long operation work is finished send the results to the client using the client call back proxy field.

   public class LongOperationService:ILongOperationService
   {
       ILongOperationCallBack clientCallBackProxy;
       public ILongOperationCallBack ClientCallBackProxy
       {
           get
           {
               return OperationContext.Current.GetCallbackChannel<ITrialServiceCallBack>());
           }
       }
   
       public bool StartLongOperation(....)
       {
           if(!server.IsBusy)
           {
                //set server busy state
               //**Important get the client call back proxy here and save it in a class field.**
               this.clientCallBackProxy=ClientCallBackProxy;
               //start long operation in any asynchronous way
               ......LongOperationWorkAsync(....)
               return true; //return inmediately
           }
           else return false;
       }
   
       private void LongOperationWorkAsync(.....)
       {
           .... do work...
           //send results when finished using the cached client call back proxy
           this.clientCallBackProxy.SendResults(....);
           //clear server busy state
       }
       ....
   }
   

4. In the client create a class that implements ILongOperationCallBack to receive results and add a method to start the long operation in the server (the start method and the event manager don't need to be in the same class)

   public class LongOperationManager: ILongOperationCallBack
   {
   
       public busy StartLongOperation(ILongOperationService server, ....)
       {
           //here you can make the method async using a TaskCompletionSource
           if(server.StartLongOperation(...)) Console.WriteLine("long oper started");
           else Console.Writeline("Long Operation Server is busy")
       }
   
       public void OnResultsSend(.....)
       {
           ... use long operation results..
           //Complete the TaskCompletionSource if you used one
       }
   }
   

NOTES:

1. I use the bool return in the StartLongOperation method to indicate that the server is Busy as opposed to down, but it is only necessary when the long operation can't be concurrent as in my actual application, and maybe there are best ways in WCF to achieve non concurrency (to discover if the server is down, add a Try/Catch block as usual).

2. The important quote that I didn't see documented is the need to cache the call back client proxy in the StartLongOperation method. My problem was that I was trying to get the the proxy in the working method (yes, all the examples use the call back client proxy in the service method, but it isn't explicity stated in the documentation, and in the case of a long operation we must delay the call back until the operation ends).

3. Do not get and cache twice the call back Proxy after a service method has returned and before the next one.

Disclaimer: I haven't added code to control errors, etc.