The Argument for WCF Hosting in .NET Core

Should Windows Communication Foundation (WCF) Hosting be Supported in .NET Core? To a lot of people this seems like a strange question; the answer is obviously... yes? no? Well actually it is quite contentious with people on both sides of the issue fiercely arguing for their position.

The arguments have become so heated, that in January Barry Dorrans, a member of the WCF for .NET Core project, had to suspend all debate on the issue. We’ll try to unpack the debate, starting with the proponents.

Jan Johansson started a thread in 2016 asking people to list the features of WCF they use and want in .NET Core. As you can see from the consolidated list below, developers actually are taking advantage of many of WCF’s advanced features.

A transactional queuing programming model

• Behaviors
• Bindings
• Context
• Contract based programming model
• Contract Behaviors
• Contract-based Coding Model
• Discovery
• Durable services
• Endpoint Behaviors
• Extensibility
• Extensibility model
• Headers
• Instance Management
• Interception-based Pipeline
• Message inspectors for instrumentation and access to SOAP headers
• Metadata Exchange
• MEX endpoint and MEX framework
• Named pipes
• Net.Pipe Binding
• Net.TCP Binding
• NetTcp (half-duplex)
• Operation Behaviors
• OperationContext
• Ordered Messages
• Queued Services
• Reliability
• Security
• Self-hosting using ServiceModel.ServiceHost
• Service Behaviors
• System.Transactions
• Throttling

Note that these are all WS-* or WCF specific features. For example, when they say “reliability” they actually mean WCF’s support for the WS-ReliableMessaging standard.

WCF Today

Many people have the impression that WCF is only used for legacy code. But actually, there are many companies that are actively investing in WCF based software. Here are some examples,

Oliver C. Lanz writes,

A specific business case I have, is that we have an investment management system with several million lines of code for which the server side is currently hosted on premise on MS Windows Servers at about 200 insurance companies and banks worldwide. We have about 100+ service types, of which in the largest installations there are 700 to 800 concurrent service instances at play. Our product is driving important parts of the core businesses.

The expenditure on IT is huge for our customers. This is also the place where we are looking to make major improvements over the coming years. A part of that is to find alternative hosting environments. A favorable choice would be Windows Nano, or the .NET Core on Linux. For being able to adopt .NET Core (or Windows Nano) we are missing the WCF server side.

Since we are very happy with WCF as a programming model, there is no incentive to rewrite our applications other than that WCF server side is unavailable in our future hosting environments. Particular features that we use is long. But to start .NET Core adoption are, these are the important ones:

[...]

Yes. We would continue building WCF services also on .NET Core.

Niplar writes,

Over the past six years, the solutions I have been involved in (in the .net area), we have always relied on WCF to handle the service layer (behind the firewall & intranet) of the solutions. Nothing out there gives us the same level of flexibility and support for different communication channels like WCF does.

I have been holding back moving to .net core for production environments for the lack of WCF support specifically. Not supporting WCF server on .net core creates a need to rewrite a lot of infrastructure code; which will probably end up mimicking the WCF programming model anyway.

The biggest solution I worked on was used by over 300 health care institutes, rewriting the server layers and functionalities is a big investment to say the least, not to mention high risk.

In fact, in that same solution we were looking at a way to unify the programming model between server and embedded devices (Linux) for new products. Supporting WCF services on .net core (not just clients) could've been a really big help and cost saver as there would be no need to have two development teams; but instead have a larger singularly focused team.

Fernando Ferreira Diniz de Moraes writes,

My scenario is pretty much similar to [Oliver C. Lanz], except that my business case is Point of Sales. Like him, we have our application deployed to numerous stores worldwide. We are also looking for alternate ways of hosting our application in order to reduce infrastructure costs. As [Jan Johansson] said, agnostic deploying WCF services would be great and would give us a huge flexibility.

WCF plays a major role in our application: it is based on a plug-in architecture where which plug-in is basically a WCF Service, so communication between plug-ins are actually WCF calls. Changing this aspect would mean have to rewrite/rethink a lot of infrastructure code.

In our case, self-hosting using instances of ServiceHost and the Contract based programming model is crucial. Our plan is not only migrate existing services, but also create new services.

Websitewill adds,

I have done a lot of projects that leverage the many aspects of WCF. Most of what I leverage in WCF (pretty much everything) is currently missing from .NET Core. Much of this missing capability would require various 3rd party libraries (or extensive custom code) to fill in the gaps and it's just not worth that level of investment when WCF already works, brilliantly. WCF is, above all else, a great productivity enhancer for my teams.

The biggest piece missing for me, currently, is the extensibility model that WCF provides.

Most of my projects leverage the capability to completely decouple cross-cutting concerns from my other components (which are light-weight WCF services). WCF provides a fantastic mechanism for doing this without the need of 3rd party Aspect Oriented Programming libraries. Developers don't know (or even care) and can focus solely on delivering the business value of the features they are concerned with.

We also leverage many other aspects of WCF such as:

named pipes, transactional queuing programming model, enforcement (not encouragement) of interface-based design, security capabilities, process isolation, error masking, I could go on.

Without WCF (or equivalent capabilities) in .NET core, I would lose way too much productivity and cannot justify the switch. It would be great to have all of these powerful capabilities in a platform that can be used in any type of environment. Imagine, productivity of WCF plus cost-savings of cheaper hosting environments. That is a tremendous business value.

Pavel Dvorak goes so far as to claim WCF is why they are using .NET,

Absolutely support the idea of having server-side "WCF" in .NET Core. We just finished another fairly large almost entirely server-side processing system ("the user experience is that there isn't any") Initially we went through a lot of pressure not to use Microsoft/ .NET mostly due to the relative advantages of other (open source) stacks when doing "microservices-based" solutions just as traditional web services. But the benefits of WCF, such as the enforced contract-based programming model, the availability specifically of Named Pipes binding, flexibility of end points and bindings (yes, declarative approach/configurability can be an advantage), security, extensibility for utilities such as logging, were really key when the system grew and required scale and performance as well as maintainability and having really very little plumbing code. The obvious next step is proper containerization (we have been explicitly waiting for Nano Server) and in general being able to port the system to the next generation of runtime platform(s) without losing any of the current qualities.

You can see more examples of developers endorsing the use of WCF in development in the thread titled Server side WCF #1200.

Why was WCF hosting not originally included?

As always, one answer is that it is simply an issue of manpower. There are only so many developers and they can’t get to everything. Ron Cain of Microsoft explains,

For the record, the "missing" features of the full .NET framework's WCF were not deliberately excluded from .NET Core WCF. Rather, the initial goal was to support all the existing Windows Store WCF API's on NET Core (which are all client-facing) before tackling other mission-critical features of WCF. It might help to know that much of the work of porting WCF features involves re-implementing OS-level libraries that WCF depends on (e.g. socket layer, cryptography, etc.) to allow it to work cross-platform. So, lighting up WCF features usually involves replacing OS-level libraries for each platform first. It might help to think that the "W" in WCF is no longer a given in NET Core.

This is one reason why it is so valuable to hear from you which features matter most, because it lets us investigate more deeply questions like "Which libraries are required to do feature X on Linux? OS X?, etc.". Please keep those suggestions and specific scenarios coming!

Why not just use REST?

The most common criticism about WCF is that its redundant with ASP.NET WebAPI and REST. To that Jörg Lang responds,

Messaging between services is important and when doing enterprise backends, REST is not going to work. It lacks too many things like others have mentioned. So certainly Transactions, Queues Messaging, Named Pipes, Extensibility should be supported by .Net Core

So, .NET Core has to provide those things in one way or another. If it is called WCF I don't care. Maybe it would be the opportunity to fix some of the weaknesses of WCF like the overly complicated configuration story and replace it with a convention based approach.

Also you should/must support other Messaging frameworks beside MSMQ or Service Bus. In general support of AMQP would be nice, including the various messaging patterns.

Agustin M Rodriguez echoes that thought,

WCF has been instrumental in delivering quality services that scale and deliver reliability by leveraging transactions across the wire (System.Transactions). Without support of WCF on .NET Core we would lose many of the "Free" benefits we get thru the extensive WCF interceptor chain, including logging, behaviors, and context flow.

For Scott Hurlbert the allure of WCF is that it doesn’t have to use HTTP at all,

These two lines of code are just a sample but what's interesting here is that the Binding and the Endpoint schema are components:

Binding binding = new BasicHttpBinding();
IMySimplestService proxy = ChannelFactory<IMySimplestService>.CreateChannel(binding, new EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

This is interesting because it means that by swapping those out WCF can communicate over Http/https, UDP, TCP-IP, MSMQ, NetPipes and a bunch of other protocols and endpoint schemes.

I understand that in the recent web many have forgotten about anything other than HTTP, but if your app grows you may find yourself wishing you had the ability to use the exact same code, but pointing to a queue'd endpoint. Sadly, most other frameworks will leave you re-implementing your system for queueing rather than just repointing it.

Not to mention transactions (also fallen out of favor - UNTIL they are essential) and various forms of authentication and encryption and on and on.

Catalin Pop is likewise focused on how WCF is an abstraction over various protocols,

Yes, there are a gazillion frameworks, large and small, more “enterprisey” or more 1337 h4x0r oriented, with different options and patterns, some rigid and some flexible ... and ... this is exactly the problem ... there's no base line.

WCF should help to get rid of all these disparate options and provide an unified and abstracted communication framework that is a base line for .Net. development.

You want binary protocolX instead of http, sure, you plug that in. You want Oauth2 instead of windows auth, sure, configure that one, you want to use NServiceBus plug in an NServiceBus binding. You want to somehow transfer contexts like a Transaction scope over the wire, you can plug that in too. The application programming model stays the same.

RPC in itself isn't a complicated thing from an .Net application point of view, you call a method or receive a call. What makes it complicated is the multitude of ways and frameworks, with security, format, feature and other options that you can implement it in.

This is where WCF should come in, and that's the point of WCF.

“WCF is too complicated”

A common criticism of WCF is that it is too complicated. And to be fair, it often is implemented in a very complicated fashion. But as Scott Hurlbert points out, it doesn’t have to be that way. Below is the code necessary for a complete WCF client and server.

This is an ENTIRE Wcf service:

[ServiceBehavior]
public class MySimplestService : IMySimplestService
{
    public string Echo( string pInput )
    {
        return $"I heard you say: {pInput}";
    }
}

Here is the interface:

[ServiceContract]
public interface IMySimplestService
{
    [OperationContract]
    string Echo( string pInput );
}

Well, maybe hosting the service is hard. Nope. Here is the service hosted and called. This is the code in it's entirety:

var myServ = InProcFactory.CreateInstance<MySimplestService,
IMySimplestService>();
Console.WriteLine( myServ.Echo("Hello World") );

There's just nothing that is enterprise quality and as simple.

I think WCF has gotten a strangely bad rap because people implemented it in unbelievably complicated ways. Believe it or not, for .net on both sides of the wire, this is all that's needed. With the ServiceModelEx framework from iDesign you can even build a proxy on the fly:

Binding binding = new BasicHttpBinding();
IMySimplestService proxy = ChannelFactory<IMySimplestService>.CreateChannel( binding, new EndpointAddress( "http://localhost:8008/" ) );
proxy.Echo("Hello");

Seriously, that's four lines of code (out of a total 17 with the structural) to create an enterprise service, it's proxy and make the service call. That's not legacy, that's productivity.

Note that even this is actually more than you need. If you are using a proxy generator, the service class can act as its own service contract without the need for a separate interface.

The opportunity cost argument against WCF

Blake Niemyjski sums up the real argument against WCF: opportunity cost and bad experiences in the past,

I don't think server side WCF is worth the investment when things like SignalR and tooling should take precedence. I've always had such a hard time with WCF client Config that I despise it :( please correct me if I'm wrong... But why wouldn't web API be the way to go... It's lightweight and gives you everything you'd need to build apps that can work from any platform with a simple http call...

Leave security, transactions, pub/sub up to the implementer...

Several other developers echo the that “WCF and VB.NET” are not worth investing in. (Equating WCF with VB.NET seems to be a common theme in these debates.) However, Catalin Pop takes issue with this stance,

[Leave security, transactions, pub/sub up to the implementer...] is the worst piece of advice anyone can give. Security should never be left to the implementer, it's the source of most atrocious security bugs ever .... There are really few security experts or developers capable of implementing security details properly, this is a job for less than 1% of the programmers out there.

Where does Server-Side WCF stand now?

Back in June of last year Jeffrey T. Fritz wrote,

There very much is a WCF team, and we are working on features to ensure compatibility with Windows 10, Windows Server, and Windows Containers.

We had a very successful presentation at Build where we showed the first of our Windows Containers. Work is continuing in that space, and we plan to continue in these investments.

WCF for .NET Core is very much on our radar, and we are working with the ASP.NET Core to prioritize this work. We will share more details when they are available to broadcast publicly.

While some of the low-level libraries needed by WCF have been ported to .NET Core and/or added to .NET Standard, no real progress has been made on WCF hosting itself. In March a separate thread titled Call for Decision: Server-Side WCF was created and tagged with the .NET 3.0 milestone.

More recently Immo Landwerth wrote, “We won’t bring [...] WCF hosting in the .NET Core 3.0 time frame but depending on customer feedback we’ll do it later.”

The source code for WCF is available on GitHub under the MIT open source license. So in theory a community sponsored version of WCF for .NET Core is feasible.