Server side WCF

[jan-johansson-mr]

Hi,

I'd like to start a thread to have a dialog about server side WCF on .NET Core. For me the WCF stack is quite impressive, and support for server side WCF on .NET Core would be fantastic. Please feel free to add your opinions to the thread.

Here is a list of some of the WCF features (that comes to my mind):

• Throttling
• Reliability
• Ordered Messages
• Bindings
• Instance Management
• Behaviors
• Transactions
• Security
• Discovery
• Metadata Exchange
• Extensibility

These features and more are for me very desirable, but some might be harder to support (e.g. WCF transactions relies on MS DTC (as fas as I know), but transactions enabled communication on a server side is a very important feature).

I hope you're as excited as I am about WCF, and even more so for a server side WCF on .NET Core.

[guybar]

Hi,

I too appreciate WCF, and use it a lot.
For me the most important features are:

• Security
• Extensibllity
• Behaviors
• Bindings (Especially TCP.Net)
• Metadata Exchange
• Instance Management
• Reliability

I think this could really be a showstopper for .Net core, if it will not have WCF server side support.

Guy

[menaheme]

Helllo,

We also use WCF extensively in our applications.
To add to the lists above we also use:

• queued services

Menahem

[reifnir]

WCF applications on Core would be a huge boon.

The only thing I would explicitly like to add to the OP's features are all of the behavior types (not just the ones available in Service Fabric)

• Operation Behaviors
• Service Behaviors
• Contract Behaviors
• Endpoint Behaviors

I distributed transactions are a prohibitive factor, they can be thrown out the window though.

[dotnetchris]

Service Bus binding of WCF is absolutely amazing for building push based reactive applications

[kscelfo]

I do consider a full WCF implementation to be a prerequisite for moving to .NET core. Without it, it will remain a variation of the .NET Framework that cannot be utilized behind the firewall of major enterprise applications that employ Service Orientation. The major features I rely on that haven't been mentioned are:

• Net.TCP Binding
• Net.Pipe Binding
• Interception-based Pipeline
• Context
• Headers
• Contract-based Coding Model

The two bindings are required to enable the efficiency of communication that Service Oriented systems require behind the firewall.

The interception is critical to allow architects to provide the necessary aspects of the system in a way that does not require the developers to do anything except code as they normally would.

Contexts and Headers are required to propagate information that is ubiquitous through the application’s stack from the client layer all the way down to the data layer and back up again without affecting the call contracts. Here, I’m thinking about identity information as a universal example.

The contract-based coding model is really necessary to avoid going back to the string-parsing voodoo that had us living in a type-uncertain, data-validity-in-question wild-west back when Microsoft thought passing hash tables to and from SOAP web services was a good idea.

[jan-johansson-mr]

Thanks for input. The implementation of back-end systems needs a mature communication stack, such as WCF. As you pointed out in the thread, a .NET Core positioned on the client side is in my mind taking away the potential of what .NET Core can be.

I'm sure we all can wire basic communication (TCP, HTTP, ...) and then get bogged down into details about message parsing, to get some implementation of back-end on .NET Core. I'll stick my neck out and claim that WCF takes a lot of plumbing away from development (reduces waste and error prone code), letting us focus on business value. That is the reason why I enjoy WCF so much, and really would love to see support for server side WCF in .NET Core, rather sooner than later.

[EricaMo]

Thanks for all the feedback on WCF Server top features! Keep it coming!

Providing WCF Server support for .NET Core is on the radar.

As you know, our current POR is to provide the WCF client-side libraries in .NET Core to enable UWP/ ASP.NET Core/.NET Core applications to call .NET Framework based WCF Services.

We are very interested to better understand your scenarios where WCF server side functionality is required.
Is this blocking your adoption .NET Core?
Do you have active projects on .NET Core for WCF Server scenarios? (We would like to partner closely with you)
Would you plan to port over your existing services or is this for needed new development?

[olilanz]

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 world wide. 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:

• Self-hosting using ServiceModel.ServiceHost
• NetTcp (half-duplex)
• Message inspectors for instrumentation and access to SOAP headers
• Behaviours
• OperationContext
• Contract based programming model

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

[jan-johansson-mr]

In my case it is needed for new solutions, where WCF services can be agnostic deployed (Windows, Linux, OSX, cloud) on .NET Core.

[niplar]

Over the past 6 years, in 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 embeded 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 2 development teams; but in stead have a larger singularly focused team.

[fefedimoraes]

My scenario is pretty much similar to @olilanz's, except that my business case is Point of Sales. Like him, we have our application deployed to numerous stores world wide. We are also looking for alternate ways of hosting our application in order to reduce infrastructure costs. As @jan-johansson-mr 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.

[Suriman]

Hi,

For us the most important features are:

• Behaviors.
• Bindings.
• Transactions.
• Headers.
• Self-hosting.
• Integration with WF.
• Queued Services.
• MEX.
• Binary Serialization (intranet communications).
• Callback operations.

Responding to Erica:

1. Yes, at least it is delaying.
2. Yes, we are migrating our application that also uses WF.
3. For both scenarios.

Thanks!