28 October 2018

Why isn’t WCF supported in .Net Core?

Development shops that have invested heavily in WCF have been left high and dry by the emerging .Net Core ecosystem. Despite clear demand there don’t appear to be any plans to add server-side WCF development to the .Net Core roadmap.

A discussion on GitHub was kicked off in 2016 and closed in early 2018 after things got a little over-heated. A survey was also published in 2017 to canvass opinion. The implication is that priorities lie elsewhere and there are no plans to formally port WCF to .Net Core.

This is a real problem for organisations who have bet the farm on WCF. Although .Net Framework will continue to be supported, Microsoft are shifting the focus of their attention to .Net Core which will receive the bulk of functional enhancements. Microsoft also explicitly recommend choosing .Net Core over the .Net framework if you want to build high-performing, scalable systems or leverage containerisation.

Entire corporate ecosystems have built their service integration on top of SOAP. WCF is particularly prevalent in on premise applications that integrate with a centrally-hosted service infrastructure. These environments tend to make heavy use of Microsoft’s proprietary TCP bindings to provide acceptable performance as well as the various WS-* standards involved in securing communications.

Caught by the rise of REST?

This has led to howls of anguish from a development community who feel they have been left behind. You can sympathise with their pain here. For many years, WCF services were regarded as the tool of choice for remote application integration. The guarantee of cross-platform operability might have been a little shaky, but developers liked the programming model and it was possible to build stable and scalable web services for application-scale integrations.

WCF has been undermined by the rising popularity of REST. The programming model in WCF is geared around operations rather than resources so it struggles to support genuinely resource-orientated, “RESTful” APIs. The best it can manage is providing a kind of faux REST, or “methods over HTTP” via the webHttp binding.

Microsoft’s response to REST was to designate ASP.Net WebAPI as the platform of choice for RESTful API development. This effectively shot the whole “one programming model, any implementation” promise of WCF in the head. Now we were being told that if you want to build modern web applications then we should not be building services with WCF.

Added to this is the growing popularity of gRPC as an alternative means of contract-first development. The format allows you to define genuinely cross-platform operations and models that are tolerant to change.  The HTTP2-based transport is fast and provides features such as bi-directional streaming and flow control. Microsoft are including a gRPC template in .Net Core 3.0 which doesn’t bode well for WCF.

Why hasn’t WCF been ported to .Net Core?

Microsoft have open-sourced a client library for WCF, mainly to provide support for consuming SOAP based services in .Net Core. They have also made IDE tooling and command-line utilities available for generating .Net Core proxy classes from SOAP-based contracts. The server stack remains bound to the .Net Framework.

There are some practical obstacles to implementing a .Net Core server stack. Part of the problem is with the “W” in WCF, i.e. “Windows”. Much of the work of porting WCF to a cross-platform paradigm will involve re-implementing operation system libraries, particularly in areas such as socket layers and cryptography.

Given that WCF is such a sprawling and involved framework, it can be difficult to gain a consensus around the “essential” feature set. It provides support for a range of different protocols, has implemented many different ws-* standards and offers a complex extensibility framework that is baked into many implementations. There is no such thing as a “standard” or “common” WCF implementation.

Added to that are the various architectural debates around whether some features were good ideas to begin with. For example, transactions can encourage service coupling, ordering should arguably be solved in business logic rather than a messaging layer, and proxy generation can give rise to RPC-style services with chatty integrations. WCF evolved over a long period and not every idea or feature is universally loved.

Perhaps the sheer effort required in implementing the full framework is the main obstacle. The experience of porting the Entity Framework to EF Core may give anybody pause for thought. The project has long struggled with complaints around missing features and performance issues. The planned port of Entity Framework 6.3 to .Net Core 3.0 will only offer a “partial version” as Microsoft have recognised that “porting legacy database code […] isn’t necessarily easy”.

Why not open source the problem?

In the absence of any “official” WCF implementation, Microsoft appear to have left the door open for a community solution to emerge. This has yet to coalesce into active development despite some clear community support. Other open source alternatives to WCF are pretty thin on the ground.

In 2016 Microsoft published an example of how middleware can be leveraged to host a SOAP based service. This was extended into a more rounded library called SoapCore that is available in both GitHub and NuGet. This hasn’t gained a great deal of traction, though it remains the only significant attempt to enable SOAP publishing through .Net Core.

The problem is that developers don’t care so much about SOAP. It’s the programming model exposed by WCF that developers want to see. They have become accustomed to defining a service model based on contracts and behaviours and applying a separate channel model of formats, transports and protocols. The problem is that it has given rise to a framework that is too big, too “Windows” and perhaps too dated to make it to .Net Core.

Filed under .Net Core, SOA, Web services.