Future of WCF?

Topics: Web Api
Feb 14, 2012 at 4:32 PM

With the merger of ASP.NET MVC and migration to ASP.NET Web API, what's to become of WCF?  Will it only focus on SOAP / WS-* protocols?  I like the ASP.NET integration, but don't fully understand why a communication framework for service architecture is migrating under web development.

If anyone on the Web API team could clarify their reasoning and what this means to WCF developers it would be most appreciated.

Coordinator
Feb 14, 2012 at 5:42 PM

WCF is still alive and well. WCF ships in the Framework and it will continue to be supported until the sun explodes. The REST support in WCF is still useful for cases where you have existing SOAP services that you need to continue to support but you also want to support REST to reach more clients.

The merging of the WCF and ASP.NET teams was done to have a single team that focuses on the Azure application platform. Certain synergies were also realized – for example, we decided we don’t need two ways to do REST, hence ASP.NET Web API. WCF is still the platform of choice for high performance backend communication (net.pipe, net.tcp support) and interoperability with 3rd parties over WS-*.

Daniel Roth

Feb 14, 2012 at 7:06 PM

WCF is here to stay but most of the HTTP/Web API support is moving to ASP.NET Web API. One thing to emphasize is that Web development doesn’t simply mean “HTML pages” anymore. Providing Web APIs for programmatic access by clients (AJAX, etc.) has become a very common way of accessing functionality exposed through HTTP. That’s what ASP.NET Web API is targeting.

Thanks,

Henrik

From: DGDev [email removed]
Sent: Tuesday, February 14, 2012 8:32 AM
To: Henrik Frystyk Nielsen
Subject: Future of WCF? [wcf:312982]

From: DGDev

With the merger of ASP.NET MVC and migration to ASP.NET Web API, what's to become of WCF? Will it only focus on SOAP / WS-* protocols? I like the ASP.NET integration, but don't fully understand why a communication framework for service architecture is migrating under web development.

If anyone on the Web API team could clarify their reasoning and what this means to WCF developers it would be most appreciated.

Feb 14, 2012 at 7:12 PM
Edited Feb 14, 2012 at 7:13 PM

This is excellent information.  Can't show enough appreciation to you and the teams involved - working collectively to make this such an exceptional product.  There's some great work being done here that has allowed our team to implement a powerful REST API with such ease.

Thanks for clearing up my questions Dan/Henrik.

Feb 16, 2012 at 6:01 PM

Our project is (or was) migrating from an existing WCF project to WCF WebApi. The APS.NET MVC 4 Beta is available, but the download is an installer. Are the signed binaries available and see what this means to my project without the installer?

Coordinator
Feb 16, 2012 at 6:09 PM

We will have our NuGet packages up later today.

Daniel Roth

Feb 16, 2012 at 8:01 PM

That is very super awesome. Same package name "WebApi.All"?

I noticed that the source (at least here on codeplex) for both this project and the mvc project hasn't really changed since the November time frame. Did I miss where that went?

Thanks!

Feb 16, 2012 at 8:31 PM

And my question is will the WebApi be useable outside in an MVC 3 app or must we upgrade our sites to MVC 4?

Feb 16, 2012 at 8:47 PM
Kwak wrote:

That is very super awesome. Same package name "WebApi.All"?

I noticed that the source (at least here on codeplex) for both this project and the mvc project hasn't really changed since the November time frame. Did I miss where that went?

Thanks!


The package is now http://nuget.org/packages/AspNetWebApi for WebHost (inside an Asp.NET app), and http://nuget.org/packages/AspNetWebApi.SelfHost for SelfHost (console app or whatever).

Feb 16, 2012 at 8:48 PM
Citezein wrote:

And my question is will the WebApi be useable outside in an MVC 3 app or must we upgrade our sites to MVC 4?


You can try using the WebApi binaries (http://nuget.org/packages/AspNetWebApi) in an MVC 3 application but this is not a supported scenario.

Coordinator
Feb 16, 2012 at 8:54 PM

Yes, you can use ASP.NET Web API side-by-side with MVC 3.

Daniel Roth

Coordinator
Feb 16, 2012 at 9:08 PM

The new ASP.NET Web API package is here:

http://www.nuget.org/packages/AspNetWebApi

We haven’t published the source yet, but we will in the upcoming weeks.

Daniel Roth

Feb 17, 2012 at 4:29 PM

So, just to be clear. There is not going to be any future development of WCF WebApi?

The ASPNET WebApi model is nice, but is there any clear path for those of us migrating an existing WCF Service to WebApi like there was with WCF WebApi -- for example, can you point me to a sample that shows ASPNET WebApi being hosted in an WCF Service? The model is obviously very different (no ServiceContract, DataContract, UriTemplate, etc...).

Feb 17, 2012 at 4:50 PM

Here's a sample of running Web API in selfhost (which is implemented usign WCF): http://code.msdn.microsoft.com/ASPNET-Web-API-Self-Host-30abca12

Coordinator
Feb 17, 2012 at 4:58 PM

Just to be clear – there is actually very little WCF code in our self-host implementation. We sit right on top of the WCF HTTP transport. None of the WCF dispatcher is used.

Daniel Roth

Mar 26 at 8:56 PM
danroth27 wrote:
WCF is still alive and well. WCF ships in the Framework and it will continue to be supported until the sun explodes. The REST support in WCF is still useful for cases where you have existing SOAP services that you need to continue to support but you also want to support REST to reach more clients. The merging of the WCF and ASP.NET teams was done to have a single team that focuses on the Azure application platform. Certain synergies were also realized – for example, we decided we don’t need two ways to do REST, hence ASP.NET Web API. WCF is still the platform of choice for high performance backend communication (net.pipe, net.tcp support) and interoperability with 3rd parties over WS-*. Daniel Roth
Hi Daniel, does above still applies?
Jul 31 at 10:01 PM
What aspects of REST do we really need, the HTTP verbs not really, exception/error handling we need a standard maybe in the HTTP response boy would do, but mostly sending a bear none SOAP message, in the HTTP with content, so we can grab the content from a JavaScript client an do an eval to deserialize it to a JavaScript object.