title: Delegating a synchronous WCF call to start an asynchronous process
body: <p>I need to modify a WCF method to run asynchronously. <code>[OperationContract(IsOneWay=true)]</code> is not a valid option in my case as the client expects a return value. I do not have control over the client's consumption of the existing WCF method call and I cannot change the signature to return <code>void.</code> I also cannot modify the client to force an asynchronous WCF call. The client will still have to expect to call its synchronous WCF call and get its hard-coded response. </p>
  
  <p>Within the service, there are behaviors in place to manage monitoring and exceptions. The option that I was considering would be to have the WCF service self-register or self-discover its endpoint, add a One-Way WCF method to the service, and have the synchronous method call the One-Way method over WCF. I felt that would be the safest way to ensure that all of the existing behaviors still applied. The behaviors don't collect or depend on any information from the end client. While it seems technically possible to start other threads or asynchronous calls from within the existing synchronous call, I don't like that as I believe it could corrupt state information that, at this point, is tied to the current WCF OperationContext. </p>
  
  <p>It seems that all options that I've explored related to this require some sort of compromise and that the option of having the synchronous call forwarded over to the One-Way call would be the safest. Is there a better way to go about this or is it possible to force a WCF method to give the same immediate return to a client as a OneWay call, but include a return value? </p>