Whither remoting?

You already know I'm a new toy junkie early adopter, so when a project that is just starting needed a light smart client talking back to a business logic server I immediately suggested using WCF. To my surprise, another architect and *my* lead developer preferred remoting, their reason? They've had very good experiences with remoting, my reason? If this system is going to live 5 years, it better uses the most looking forward technology. As I am an RD, I naively asked in the RD list for reasons to use WCF over remoting, and I got a few good responses but then the remoting camp reacted and gave good reasons for *not* using WCF. So it seems like the question is more interesting than what I thought and, before summarizing the answers I got, I would like to ask you what you think: if you were to create a client-server like application in your *intranet* would you use web services or remoting? Why?

6 Comments

  • Why don't you tell us what those interesting comments from the RD list were so we have some context.

  • both *technologies* are really good, seems to me you're using the terms interchangeably, but maybe Microsoft did this and now is confusing to talk about a specific technology (they all are web services)



    I would use remoting over WCF, but that's probably just because I've had very good experiences with it, I've seen what WCF is capable of (and is really cool), but after all it all just revolves around the same technologies that .NET remoting was built in



    just use what you feel more confortable with, I don't think there's much (if any) difference in performance one from the other, and about the future, I don't think 5 years justifies the use of one over the other one

  • Reason to use remoting: Shipping today. WCF is beta.

    Reason to use WCF: Seems to be the direction for cross system communications. I believe that remoting will be a part of it.



    If the app needs to be up and going in the next couple of months, than remoting is the way to go. if the app is 12+ months out, then WCF is probably the better direction.

  • Remoting and Web services aren't your only options. For some reason, people are always forgetting Enterprise Services and MSMQ. Not to mention that we now have Service Broker.



    My suggestion: create a logical wrapper around any technological choice so that you'll be able to swap it out for something else down the road (as long as you maintain semantics).

  • Well, MSMQ and SQL Server service broker has very especific usage scenarios: reliable message-oriented communications. Of course when you need it you need, but in my case (at least in the part of the system we are discussing) we have a more client/server, synchronous communication.



    By the way: I understand your proposal of creating a wrapper, but that of course would add an additional layer, so much for simplism ;-)

  • WCF looks to me like a very nice wrapper (already) that allows you to take a lot of different paths on how you want to transfer the data, it's definitely the one that gives you more options

Comments have been disabled for this content.