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.

8 Comments

  • Aye ;-)

    Personally I think that a bus like communication system is the way to go because it's a) inherently asynchronous due to its one-way-call-nature and b) it's the easiest purely async API I can think of.

    Like you said, I believe that APM and CallbackContracts have largely failed, too.

    Looking forward to your API ideas, especially when it comes to simplicity, ease of use and orthogonality.

    -Bjoern

  • I think it's interesting that you determine WCF to be too complex for anyone but experts, while at the same time advocating async interactions, which are intrinsically more complex due to the need of explicit fault modeling.

    "Async" seems to appeal to a lot of inexperienced developers and architects as it is a lot easier than "sync" when NOT taking faults into account. It's just that systems built this way break a lot more spectacularly as soon as these faults later indeed happen. (And more often than not, happen without anyone explicitly noticing them with the only side-effect being terminally corrupted data).

    Or to put it another way: while sync is not the most natural (and certainly not the best in many cases) way of communicating between systems, it has one big advantage: the fault handling is immediate and therefore often doesn't need to be explicitly modeled. In a lot of cases, it is enough to design contracts to be idempotent and/or safe and detect failure at the client). Even if this piece of guidance is not followed, it is easy for even the most novice developers and architects to see the failures as they happen. And *this* is what makes sync interactions so interesting for the average developer. But of course only if we agree, that HTTP 500 is better than corrupt data without any indication of failure.

  • WCF has asynchronous communication via MSMQ. Thats very much scalable and dependable. I think you can take a look at that option.

  • @Sohan: Although MSMQ can be used thru WCF it certainly is not the default. Also MSMQ requires additional admin effort so it´s often not a natural choice for developers.

    @Ingo: I agree with you that sync communication will probably always be easier than async. And yes, async systems are harder to design than sync systems.

    But then: Just because something is hard people should not be protected from it. Because if the very protection in the end is an illusion... then people later on will have an even more hard time to adapt to the truth.

    It´s quite usual to let children learn to ride a bike with training wheels. Parents try to protect their kids from falling and hurting themselves.

    Well, this sounds ok. But as experience tells, kids who learned the "hard business" of riding a bike with training wheels usually develop less of a sense for their bodies. And they never learned to fall.

    So if true scalability and more reliability only comes with async communication, then I´m all for being honest to the developer community from the first day on.

    Maybe they hurt their noses on lost data. But then this is not because of a leaky abstraction but because of reality.

    And I´m quite optimistic: Developers are able to learn async communication. Just provide them with a sandbox. Just give them easy to use async APIs. Let there be a leaning path. MSMQ wasn´t easy enough. But why not improve on MSMQ?

    If fault handling is a pain point in async communication, then make it easier. (And, please, don´t try to convince me, fault handling is a piece of cake in WCF ;-)

    But, hey, I won´t try to convince you, Ingo, to let go of WCF. WCF is cool and it´s needed. WCF is your business. Great.

    It´s just that I see lots of developers who have a really hard time doing even the simplest things using WCF. Are they all just dump programmers? I doubt it. Do they just lack proper WCF indoctrination? I doubt it.

    Rather I think communication technology has not catered to their needs yet.

    Fortunately there are alternatives to using WCF directly in applications. And please note my wording: I´m saying "directly".

    As an application developer I just don´t want to be bothered with WCF instricacies in my code. If WCF is running on lower levels and weaves some magic... great! I´m loving it. Just like TCP sockets.

    We´re talking about a communication stack. And I don´t think WCF should be the top of this stack for just all developers.

    -Ralf

  • @Tilman: Thx for your "API vision" ;-) I´d say, you´re close - but it can be even easier. Stay tuned...

    -Ralf

  • I would recommend looking at NServiceBus.

  • >> usability and understandability like .NET Remoting

    Do you have examples of this? What is more understandable and usable in .NET Remoting?

  • Interesting post.

Comments have been disabled for this content.