A Week With WCF

We are at a point where what was our internal API now must live in the wild as some business partners now need access to different levels of our engine. I’ve written those awful web asmx services in C# enough to know that approach wasn’t going to cut it. I wasn’t sure people were even interested in XML any longer and some even specifically requested simple JSON. Because of my own experience tooling around with PhoneGap, I know I’d probably pick JSON too. In my own experience generic handlers make JSON much easier to dispense, yet they felt a lot like asmx technology at the same time.

SOAP? We’re not even going to discuss that.

Anyway, I briefly considered just plain MVC, but that didn’t seem like it would scale right. I had no data, this was just a first glance, “well, it can’t be that simple”.

I arrived later at WCF REST Services. Seemed easy enough, I downloaded the samples and had it running quickly. I could inject my own authentication and filters through the servicemodel RequestInterceptor, and it was fairly easy to see how I would map my routes to the things I wanted to expose.

But then it wasn’t. When you look at the configuration sections of the web.config, things certainly enter the realm of Java configuration hell. There is a tool SvcConfigEditor.exe that can help you configure your services and their endpoints, but it failed when trying to edit my ApiKey example. “The behavior needs a name”, so I gave it one, except, then the behavior didn’t actually execute. I fixed that, but wound up getting a little tired of the endless possibilities here.

As an aside, why couldn’t “SvcConfigEditor.exe” be named “Service Configuration Editor.exe”?

After hours of fiddling, I had some of my own examples or tests running and was relatively happy with how things would work. Each service has an interface that defines the service’s contract and each service makes it easy to map different actions and their parameters that you might want to expose. JSON was easy to wire up then as well.

Then I decided to try a client against the service. Hmm, No JSONP?  Well it turns out you can do JSONP, but it certainly felt like I was “fiddling”.

This is where I hard stopped; so much fiddling felt overtly enterprisey to me, and the red flags went up in a 21 flag united wave.

I didn’t need my services accessed over anything but http/s, so most of the other things in WCF were starting to feel like extra things I wouldn’t get to use either.


I went back to MVC 3, and started setting up interfaces and classes just like the service model in WCF. Ok, easy enough. With some help from Matt Otto on the routing, I recreated in two or three hours what took me in WCF almost a day and a half to do.

I totally over-engineered. Guilty.


I think the problem with things like WCF is that their true audience is probably very small; enterprise level stuff. Where a true SOA might be in place. Out in the cloud however, http/s rules the day and I can do the same thing with far less overhead in MVC. Its sort of like EnterpriseLibrary and log4net; the fact is, I just need to log, I don’t want to spend countless hours configuring and setting up something so that I can use but 10% of the functionality.

I’m glad to have taken a look at WCF, but ultimately, I don’t think it fits our need at this time. It wasn’t time wasted however, I thought a lot about simple things, like urls and REST. Let’s call this a learning week. I learned, and it was good.

But that is a post for another day.