WCF for DNX Core a waste of time?

Recently Microsoft released the source code for a port of WCF to the core framework. https://github.com/dotnet/wcf

WCF has a reputation for being amazingly complex and attempting to handle communication of any sort. It is a throw back to a time when SOAP based communication was all the rage. Very few new projects seem to make use of WCF except to provide interoperability with older application, integration which could, arguably, be provided in a simpler, more testable fashion. 

The effort to port WCF to DNX core must have been monumental. In a world where tons of work is needed still on ASP.net 5 and its tooling was it wise to throw so many resources behind a WCF port? Is the market for WCF completly disjoint from the market for ASP.net 5?



5 comments

Robert Greyling
5/21/2015 9:54:16 AM
Personally, I feel like the port to WCF is a big waste of time and resources - but that's personal because I know that I'll never use or recommend it given past experience. However, I feel like this decision can be defended in the sense that the base of enterprise that Microsoft support is absolutely vast. There are still a significant number of large companies who have very bureaucratic limitations and who must, without fail, stick to Microsoft sanctioned code only. In those situations, the developers and companies will be held back on an older version of the .Net framework indefinitely if there happens to be a WCF implementation in production somewhere. By porting WCF, I feel that Microsoft have given those developers a way out to progress despite some very tight controls and red tape.

Mike Johnson
5/21/2015 1:53:01 PM
Usually WCF is deployed in situations where SLA and 3+ 9's are part of the conversation. if its down, weekends are lost, vacations are cancelled, money is lost and bonuses aren't paid. No one would suggest using this for a green project on the drawing board that's for sure, but long running programs that got green lighted a long time ago having this still be alive is great news.

James Chambers
5/21/2015 2:34:09 PM
I highly doubt there are new projects coming online that are going to be built from scratch and leveraging WCF server-side. There are high-availability models that sit on HTTP with durable and responsive backends. However, I do see value - especially in the enterprise arena - where a group would want those facilities on the client side to consume legacy resources. In that vein, it seems like not a bad play. While I have doubts about the worthiness of the effort, I assume there are drivers in the corporate adoption space that suggest it's imperative that core has a WCF package available. At the same time, this was to be a departure & jump-off point, so maybe a bit of a missed opportunity to retire it, but at least it will land in a place where it's not pulled into every project.

paladinu
5/22/2015 4:24:12 PM
So the days of using for WCF for REST, API and RPC style http interactions is clearly over. I do think however that WCF is still a viable choice for communications that don't happen over http or have other concerns. Examples might be complex streaming or buffering scenarios, large data transfers, restart-able transmissions, restrictive protocol requirements or asynchronous communications with unreliable transports. It was that anything goes approach of course that make it such a beast to work with, but I'm not sure Web API has really accounted for all those different scenarios. I agree it will have continued use in connecting to legacy resources, but I think there are still problems it solves that don't always have other easy solutions. Thankfully we can all avoid its complexity mostly though because a typical web application doesn't have those concerns. I think open sourcing it was a fantastic idea though because the people who really care about it can help keep it alive and healthy. Who knows, maybe someone will even figure out a way to make it simpler.

Robert Greyling
5/23/2015 8:18:52 AM
I agree with everything you say @paladinu regarding the varied alternative uses for WCF, but something that has saved my bacon a number of times when presented the opportunity was to swap it out for ServiceStack instead. ServiceStack has the ability to cater for all of those same situations as a WCF substitute, with one added bonus - it's simpler :) ... and faster. Sometimes it's not possible though when it comes to tight IT control policies around open source, but worth considering.