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

Question

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 1

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.

Answer 2

Good question! Like yourself I've not looked at WCF before and wonder whether it render web services more or less obsolete?

On your point about Linq2SQL - given that this is a spanky new app and you're probably going to be maintaining the codebase for a good few years - personally (and at the risk of being downvoted for this - but remember it's a valid point of view!) I'd be inclined to look at the Entity Framework.

I am aware of it's faults, the biggest for me being that it is too tightly coupled to the DAL - therefore it cannot be unit tested easily (believe me, this is a BIG problem for me, although I do have a gut feeling there is a work-around to achieve this).

However, my personal opinion is that MS are just not going to let this technology fall by the wayside, and I'd have to take into consideration the rumours it will REPLACE L2S. The flipside of that is that L2S is a much more mature tech and a safer bet.

Maybe I'm being naive, but I believe Dan Simmons when he says they are working on delivering the EF (eventually) as a completely persistent-ignorant architecture - http://blogs.msdn.com/dsimmons/pages/ef-faq-entity-classes.aspx#_Does_Entity_Framework

Answer 3

I would rather look into EF then L2SQL too.

The idea of being only able to connect to MSSQL was the reason i never adopted L2SQL, from that point it was clear that MS would give up on it someday.