The time has come to say goodbye to Windows Communication Foundation (WCF). Yes, there are plenty of WCF apps in the wild — and I’ve built a number of them. But when it comes to selecting a web services stack for greenfield applications, you should no longer use WCF.
WCF is dead
There are many reasons why WCF has lost its luster, but the bottom line is that WCF was written for a bygone era and the world has moved on. There are some narrow use cases where it still might make sense to use WCF, for example, message queuing applications where WCF provides a clean abstraction layer over MSMQ, or inter / intra process applications where using WCF with named pipes is a better choice than .NET Remoting. But for developing modern web services, WCF is as dead as a doornail.
Didn’t get the memo? Unfortunately, Microsoft is not in the habit of annoucing when they are no longer recommending a specific technology for new application development. Sometimes there’s a tweet, blog post or press release, as when Bob Muglia famously stated that Microsoft’s Silverlight strategy had “shifted,” but there hasn’t to my knowledge been word from Microsoft that WCF has been quietly deprecated.
One reason might be that countless web services have been built using WCF since its debut in 2007 with .NET 3.0 on Windows Vista, and other frameworks, such as WCF Data Services, WCF RIA Services, and self-hosted Web API’s, have been built on top of WCF. Also, if you need to interoperate with existing SOAP-based web services, you’re going to want to use WCF rather than handcrafted SOAP messages.
But it’s fair to say that the vision of a world of interoperable web services based on a widely accepted set of SOAP standards has utterly failed. The story, however, is not so much about the failure of SOAP to gain wide acceptance, as it is about the success of HTTP as a platform for interconnected services based on the infrastructure of the World Wide Web, which has been codified in an architectural style called REST. The principle design objective for WCF was to provide a comprehensive platform and toolchain for developing service-oriented applications that are highly configurable and independent of the underlying transport, whereas the goal of REST-ful applications is to leverage the capabilities of HTTP for producing and consuming web services.
But doesn’t WCF support REST?
Yes it does, but aside from the fact that REST support in WCF has always felt tacked on, WCF has problems of its own. First, WCF in general is way too complicated. There are too many knobs and dials to turn, and you have to be somewhat of an expert to build WCF services that are secure, performant and scalable. Many times, for example, I have seen WCF apps configured to use the least performant bindings when it wasn’t necessary. And setting things up correctly requires advanced knowledge of encoders, multi-threading and concurrency. Second, WCF was not designed to be friendly to modern devleopment techniques, such as dependency injection, and WCF service types require a custom service behavior to use DI.
One of the first signs that WCF was in trouble was when the Web API team opted for using ASP.NET MVC rather than WCF for services hosted by IIS (although under the covers “self-hosted” Web API’s (for example, those hosted by Windows services) were still coupled to WCF). ASP.NET Web API offers a much simpler approach to developing and consuming REST-ful web services, with programmatic control over all aspects of HTTP, and it was designed to play nice with dependency injection for greater flexibility and testability.
Nevertheless, ASP.NET Web API duplicated many aspects of ASP.NET MVC (for example, routing) and it was still coupled to the underlying host. For example, Web API apps requiring secure communication over TLS / SSL required a different setup depending on whether the app was hosted in IIS or self-hosted. To address the coupling issue, Microsoft released an imlementation of the OWIN specification called Katana, which offers components for building host-independent web apps and a middleware-based pipeline for inserting cross-cutting concerns regardless of the host.
Web API is dying – Long live MVC 6!
As awesome as ASP.NET Web API and Katana are, they were released mainly as a stopgap measure while an entirely new web platform was being built from the ground up. That platform is ASP.NET 5 with MVC 6, which merges Web API with MVC into a unified model with shared infrastructure for things like routing and dependency injection. While OWIN web hosting for Web API retained a dependency on System.Web.dll (along with significant per-request overhead), ASP.NET 5 offers complete liberation from the shackes of legacy ASP.NET.
More importantly, ASP.NET 5 was designed to be lightweight, modular and portable across Windows, Mac OSX and Linux. It can run on a scaled down version of the .NET Framework, called .NET Core, which is also cross-platform and consists of both a runtime and a set of base class libraries, both of which are bin-deployable so they can be upgraded without affecting other .NET apps on the same machine. All of this is indended to make ASP.NET 5 cloud-friendly and suitable for a microservices architecture using container services such as Docker.
So when can I start building Web API’s with ASP.NET 5 and MVC6?
The answer is: right now! When RC1 of ASP.NET 5 was released in Nov 2015, it came with a “go-live” license and permission to use it in a production environment with full support from Microsoft.
Instead of hosting on IIS, which of course only runs on Windows, you’ll want to take advantage of Kestrel, a high-performance cross-platform host that clocks at over 700,000 requests per second, which is about 5 times faster than NodeJs using the same benchmark parameters.
Shiny new tools
Not only has Microsoft opened up to deploying ASP.NET 5 apps on non-Windows platforms, it has also come out with a new cross-platform code editor called Visual Studio Code, which you can use to develop both ASP.NET 5 and NodeJs apps on Mac OSX, Linux or Windows.
ASP.NET 5 is also released as open source and is hosted on GitHub, where you can clone the repositories, ask questions, submit bug reports, and even contribute to the code base.
If you’re interested in learning more about developing cross-platform web aps for ASP.NET 5, be sure to check out my 4-part blog series on building ASP.NET 5 apps for Mac OSX and Linux and deploying them to the Cloud using Docker containers.
In summary, you should avoid WCF like the plague if you want to develop REST-ful web services with libraries and tools that support modern development approaches and can be readily consumed by a variety of clients, including web and mobile applications. However, you’re going to want to skip right over ASP.NET Web API and go straight to ASP.NET 5, so that you can build cross-platform web services that are entirely host-independent and can achieve economies of scale when deployed to the Cloud.
| Reference: | WCF Is Dead and Web API Is Dying – Long Live MVC 6! from our NCG partner Tony Sneed at the Tony Sneed’s Blog blog. |
