Balancing reach and rich

I've been enjoying reading some of the reactions to our Web Programming Model features -- particularly Jef Newsom's post Some Interesting History and David Ing's Simple Object Apology Protocol. Both make some great points and are well worth the read.

Jef writes:

So, it is interesting to me to watch guys like Clemens Vasters and Don Box (and Steve Maine, though I think he was less heavily involved in 'expectorating' the WS-splat and a lot more heavily involved in consuming and evangelizing prior to getting into the big house) starting to shed the WS-Splat baggage and just GET it. And I think that they are being pragmatic about it and trying to scratch the 80% itch (GET) really well, but they are adding in a decent set of support for the REST (ha, pun, ha ha, er, um...) of the story without being to religious about being RESTful. And when questions come up like [paraphrased] "Well, shouldn't you layer soap into that?" they look very relaxed and calm as they say [paraphrased] "Nah, you're not going to need it here." From the outside, it looks a little cathartic.

Cathartic? Maybe. But I don't think the fact that we're embracing the stuff that works on the web today in any way devalues the rich protocol infrastructure we build in WCF V1. Rather, the mea cupla embodied in these bits is two fold:

  • Not every scenario requires infrastructure support for interoperable distributed transactions, or message-based security and reliability through intermediaries. And you know what? That's fine.
  • Like all scenarios, complexity should be pay-for-play. Simple things should be simple and hard things should be possible.

I'll admit that we could have done a better job internalizing that last point in V1. We did a great job of making hard things possible (the answer to "how do I turn on X?" is generally "just configure another endpoint with a different binding") but that came at the expense of some really simple stuff like HTTP GET. Sorry about that, we're making that better as we speak.

But the fact that we're coming back to the basics in Orcas doesn't mean we're deleting all that rich protocol code we wrote in V1 from the code base. This isn't an either/or decision -- our "just configure another endpoint" story is still intact, and it's really nice to have that protocol richness in your back pocket because when you

David writes:

By having such a broad choice of what to use (REST, HTTP/POX, SOAP, Remoting etc. etc.) then for the people looking for the 'one simple answer' it just gets increasingly complex and confusing. The complexity tax of these news things are start to look like the federal deficit - always going the wrong way.

This gets back to one of the major reasons why we built WCF in the first place. When we started this thing, Microsoft had a metric shedload of distributed communications API's -- ASMX, MSMQ, COM+, Remoting -- and one of the primary value-adds of WCF is that it unified all these guys into a single framework so you didn't have to learn 4 different API's and figure out how to choose between them to get your job done.

This fundamental value proposition hasn't changed in Orcas.

Rather, the API unification of WCF has just gotten bigger, because now we're bringing a whole bunch of rich HTTP scenarios into the WCF tent. With the Web features in Orcas you can use the high-level WCF programming model in places where you would normally have to start at a much lower layer of the framework (System.Net.HttpListener or System.Web.IHttpHandler) and roll a whole bunch of boilerplate yourself.

Does using WCF mean you don't have to make decisions about things like 'when do I use durable messaging?' or 'should I stick an HTTP GET head on this thing?'. Of course not -- we're a framework, not an oracle. At the end of the day, you still have to make the right call for your app. What we as framework authors can offer you is the simple guarantee that the same core set of concepts, metaphors, and programming idioms you need to learn to be productive on WCF in once scenario will help you be productive on WCF generally. You don't have to learn six wildly different API's anymore. There's a simple answer to the question of 'how do I build distributed apps on the Microsoft platform' and that answer is WCF.

As such, I think the reach programming model work we're doing now actually increases the value of the rich protocol stack in V1 because it gets rid of the traditional scenario cliff between rich and reach. Take a framework like Rails, for instance - which is optimized around making a common set of scenarios very easy. Granted, the stuff Rails optimizes for hits the 80% case. But if you suddenly have to step into the other 20% for whatever reason, you're kind of screwed (as the Twitter guys are finding out). We want to protect folks who take a bet on WCF from falling off similar cliffs in the distributed systems space. We're taking a big step in that direction with the Orcas Web features, and you can expect us to continue down that road over time.

Technorati Tags: ,
#1 David Ing on 5.16.2007 at 11:44 PM

Hi Steve, Thanks for the comments back - appreciated.What I was bringing up, albeit clumsily, was more the fact that SOAP used to represent to me the numero uno way of living with WCF, coming from that WSE heritage and so forth. I was more pointing out the fact that, in some small way, using a pure HTTP style was a hint of perhaps SOAP becoming less dominate over WCF as the 'main, let's demo that first, way'. How XSD(format) and WSDL(contract) relate to WCF used to be a bit simpler with the 'SOAP Everywhere for All', so that was more the interesting aspect of this - I failed to get that across very well. I think your follow-up posts cover this very well, and I was always in much nodding agreement as WCF possibility of being a flexibly framework, rich/reach etc - it was more on 'WCF philosophy slight adjustment' than anything else. I still think the winds have changed somewhat, and that people have extra design decisions to make (and mistakenly look at a neutral framework for advice) but that's just my personal opinion. Compared to a bunch of APIs/Stacks, the WCF story is still a much better piece of engineering than what we had before (and I know because I've shipped with both).- David