.NET Remoting vs. Web Services vs. Windows Communication Foundation (WCF)

Aaron picture Aaron · Feb 3, 2009 · Viewed 7.7k times · Source

Anyone willing to help me out with pros/cons on .NET Remoting, Web Services, and WCF? I have worked a bit with .NET Remoting and Web Services and I am architecting a new ASP.NET 3.5 web app where I will be using a SQL 2008 DB. Primarily I am wondering if it would be worthwhile to really look into WCF for this app.

In this particular instance, here are some relevant points:

  • Most persistent data will be error and usage tracking.
  • Even if I go with .NET Remoting, traffic will not warrant a physical remoting server, but I'd like to dream that it one day will!
  • At this time, I do not foresee needing to grab this data from other web apps.

However, I'd still like to know:

  • When/why would you use .NET Remoting in a web app?
  • When/why would you use Web Services in a web app?
  • When/why would you use WCF in a web app?
  • Should I consider a technology such as LINQ to SQL?
  • Are there other better options are out there?

Answer

Mike_G picture Mike_G · Feb 3, 2009

I actually switched our software from traditional .NET Remoting to WCF. The bloat in communication that occurred from Remoting was amazing (just look at a wireshark trace). Before moving to WCF i thought about using just a traditional .NET webservice, but the interfaces we implimented for our remoting calls would require to much modification (We had used some out and ref parameters which an Asp.Net webservice cant do if I am not mistaken).

Really, I cant think of a reason to go with an Asp.Net webservice, but Im not an Asp.Net guy. To me, it offers no advantages over WCF. It may be easier to go with a webservice, but the flexibility WCF offered was what I needed. Especially in the area of message formatting.

I like my WCF service because with one service I can either serve up JSON or SOAP/XML and all the protocols are supported (ipc, tcp, and http).

The bummer with WCF is that its strict bindings require you to define an endpoint for both HTTP and HTTPS if you wish to use it in a web based scenario. Unlike a traditional Webservice which "just works" regardless if its secure or not.