WCF is not the solution but the problem
The title of this post has caught your attention? So let me explain what I mean by it: I think WCF is great. It´s the best communication framework Microsoft ever has come up with. WCF solves a lot of problems of its predecessors, it is tremendously extensible, and it supports the main communication paradigms (sync, async, P2P). WCF certainly is a solution of some kind.
But to whom? Who benefits from all these capabilities of WCF? Is it the average application programmer? I doubt it.
Remember when first Webservices and .NET Remoting came out? The Microsoft developer community rejoiced. What a relieve compared to sophisticated COM+ and raw TCP socket programming. Developers were so glad, remote communication finally became easy, usable.
Unfortunately this did not last long. Webservices hit their limits and needed to be amended with tons of WS-* standards. .NET Remoting hit its limits when it turned out that remote stateful objects really were a bad idea in terms of scalability.
So Microsoft set out to unify remote communication and do close any conceptual holes. Out came true message oriented WCF, the one size fits all communication API.
Well, great. I love WCF for this.
But I don´t like it for two things:
- I strongly believe that remote communication should always be asynchronous. Yes, always. Because that´s how autonomous systems communicate. And if you deny that fact you run in all sorts of problems. It´s a case of LOLA. So WCF is betting on the wrong horse with its focus on synchronous communication. (And I say “focus” because you can do async communication with WCF. But do you really want to?)
- WCF tries to be a Jack of all Trades. Its drive to unification is so strong it has lost sight of usability. Webservices and .NET Remoting had so much appeal because they promised to finally make remote communication simple. But then they failed. Not because their APIs did not live up to the promise of simplicity, but because they too bet on the wrong horse: synchronicity.
Let me say it like this: WCF is great in the hands of experts. But Microsoft should not expect developers to become WCF experts en masse.
I feel reminded of the early 1990s. Back then there was the Windows API for doing Windows programming. And you could do cool stuff with it. But, let´s be honest, you had to be an expert for doing that. And even Charles Petzold had not been able to turn masses of developers into expert Windows GUI programmers.
Enter VB 1.0.
And the world changed completely. Suddenly just about any developer was able to do Windows GUI programming. Maybe not all outcomes were as beautiful and usably as their creators thought, but anyway. Windows GUI programming had become a mass phenomenom almost overnight.
Today WCF to me seems to be the new Windows API. So much is possible – if you´re an expert. But even Don Box and Juval Löwy together won´t be able to turn developers into WCF experts en masse.
That´s why I think WCF is not the solution but the problem. By its very nature it stands in the way of solving the remote communication problems for Joe Developer. It has made it much easier to do certain things for many developes. But still the average developer is baffled by its complexity.
Almost three years ago I wrote a small blog article on how to start using WCF: A truely simple example to get started with WCF. And since then it´s one of the most popular articles in this blog. Why´s that so? Because WCF is so darn difficult to learn, you really need all the help you can get.
That said, what can we do? Put up with WCF? I don´t think so. We need the equivalent of VB for the world of remote communication. We need some layer of abstraction on top of WCF lie VB was on top of the Windows API.
WCF is here to stay. Great!
But as an application developer I certainly don´t want to need to use WCF directly. To an application programmer WCF like Tcp Sockets are a problem, not a solution. A learning and usability problem.
We need some communication API which brings back usability and understandability like .NET Remoting, but at the same time gets it right. That means at least it must not be synchronous but asynchronous.
If you agree with me, say aye ;-)
Next time I´m going to give you an idea of how such an API might look.