The Future of WCF, Part 1
It's been two years since we shipped the first release of WCF (codenamed Indigo). It was actually even a little before that that I started thinking about what features we should include in the upcoming .NET 4.0 release.
The first time that I wrote down a list of features that I was targeting for improvement was the summer before, approximately two and a half years ago. There is always a period of time towards the end of a release where every addition is scrutinized too closely to add a new piece of work but the old pieces of work no longer require the continuous attention of everyone on the team. This is typically one of those creative periods where people are doing things such as thinking about what seems at the time as the distant future. I'll have to go check how closely that initial list compares to what we are planning to do today. I suspect that the two will read very differently.
Due to the way that the Orcas release was conceived and assembled, many of the ideas we had could only be done in the next major release. This led to us essentially planning for both releases at once. Orcas became a targeted release because there were significant restrictions on both our time until delivery and about what we could to the existing code from an engineering standpoint.
One of the things that I took notice of early on is that there were some particular biases in the types of web services that WCF was built to support. I thought that there were other interesting markets for web service developers that WCF wasn't doing a good job of catering to at the time.
WCF started with a clear bias towards SOAP, WS-* protocols, and other heavyweight standards that were being popularized at the time but had not been ubiquitously adopted. One effort underway was to continue evangelizing and spreading these standards.
I didn't believe though that you could force the world to use a single approach for building web services. You also couldn't convince everyone to completely discard and replace all of the entrenched connected systems and applications that they had been developing and investing in for the past 25 years. Realistically, you can't convince anyone, except for a rounding error's worth of people, to do that without some tangible value in return. Instead, you have to look for markets where this weakness doesn't apply or where it can be turned into a strength.
There were two markets in particular that I thought were interesting for web service developers to expand into when using WCF, which I'll talk about next time.
Comments
Anonymous
November 13, 2008
"I didn't believe though that you could force the world to use a single approach for building web services." Implicit in that statement seems to be the belief that, regardless of the approach taken, all connected systems should be built using services. That is clearly what the design of WCF is geared towards. When remoting was essentially deprecated in favor of WCF, Microsoft was saying that the only way you should ever be allowed to move data from one physical tier to another is through services. I have been trying for several years now to impress upon web service evangelists that not all valid application architectures include the need for the kind of boundaries that services enforce. Every time I try to make that argument, I am told that I just don't recognize the value of those boundaries. The things is, I do recognize that value; but I also recognize that the value is dependent on the circumstances. The C# team is adding dynamic binding to the language because there are many circumstances when static binding is simply not possible or doesn't make sense; that doesn't mean that Anders has changed his mind about the value of static typing, but the fact is that enforcing it sometimes hinders more than it helps. Similarly, the boundaries enforced by service architectures often hinder more than they help. I am trying to remain optimistic that the next iteration of WCF will take this into account. Hopefully you will address this issue in your future posts.Anonymous
January 23, 2009
Having read part 1 will be helpful. As I mentioned last time, there were two markets in particular that