Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,549

filter by tags archive

WCF Async without proxies

time to read 2 min | 225 words

I don't like generated proxies for web services, they are generally ugly and not fun to work with. However, up until recently I believed that I had to deal with them if I wanted to use the async operations for web services. As it turn out, I was wrong.

We can actually define an WCF service interface like this:

public interface IAsyncBus
	[OperationContract(AsyncPattern = true)]
	IAsyncResult BeginProcess(IMessage[] request, AsyncCallback callback, object asyncState);

	IMessage[] EndProcess(IAsyncResult result);

Now you can work with it using:

IAsyncBus bus = new ChannelFactory<IAsyncBus>().CreateChannel();
ar = bus.BeginProcess(...);
//do work

The problem with that is that on the server side, I also have to do things in an async manner. This is sometimes appropriate, but it tends to be a major PITA for a lot of things.

As it turn out, we can solve the issue with aliasing. In the interface dll, we can define:

public interface IBus
	IMessage[] Process(IMessage[] request);

public interface IAsyncBus
	[OperationContract(AsyncPattern = true)]
	IAsyncResult BeginProcess(IMessage[] request, AsyncCallback callback, object asyncState);
	IMessage[] EndProcess(IAsyncResult result);

Now, you can create an instance of IAsyncBus to communicate with IBus directory. On the server side, we implement IBus, and handle the message in a synchronous manner. Easy, simple, and doesn't require any proxies :-)



Very nice. I was completely unaware of this.


Outstanding, I'm going to go delete my proxy based code and refactor to this.

Johnny Hall

Hi. You might be interested in this alternative to using a proxy or a channel.


Ayende Rahien


Actually, I would probably use the Castle's WCF integration facility for this in real scenarios

Johnny Hall

That's my preference as well, although I'm not completely familarised with it yet.

It's an interesting piece of code though. I like the approach. I HATE the generated proxies - they're such a p-i-t-a to manage, I find.

Nati Dobkin


Async pattern is a nice ability that WCF supplies but as far as I know the server doesn't have to know about the AsyncPattern you are using for your clients.

Your code will work fine without the second contract. For your client you have to declare the AsyncPattern on your service contract mehods and when you implementing it you just have to call the standard Process method – WCF engine will do the rest for you.

You can see implementation of this pattern by running svcutil.exe with your mex address and apply /async parameter on it. You will get fully generated proxy with async pattern implemented for each and every of your contract methods, while in the serve you don’t mention anything about it.

Ayende Rahien


The point here is to avoid having to generate a proxy

Nati Dobkin


My point was to show that there is no need to write the second contract, like you did. I referenced you to generated code only for proof my concept; you don’t have to use it.

BTW, if you don’t use the generated code and your contract is changed, how do you get the newer one for your client?

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - 3 days from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats