WCF vs. Web service vs. Sockets: which to choose?

Question

I have two related questions about Web services:

(1) I'm currently writing a set of applications, and it occurred to me that maybe I'm not using the right tool for the job. Here is the spec:

• There are many Windows servers behind different VPNs and firewalls.
• Each of the servers has a Windows service running, that reports various information about it to a centralized server, via a Web service, both of which I've written, and have access to.

So I'm both the producer and the consumer, and I'm staying on the same platform (.NET). Maybe a web service isn't the way to go? I'm using one purely because it's easy to write and deploy, and I'm the most comfortable with them. Should I really be using WCF for this?

(2) In the web service, I'm creating a State object to represent the state of the server, and sending it as a parameter. However, adding a service reference creates a proxy of the State class. It seems gacky to copy the properties of the State object to the proxy, and then send the proxy. Should I just replace the proxy class with the real class in the auto-generated code (i.e., include a reference to the State class instead)?

Answer 1

If it is platform independent, I would certainly recommend WCF.

Answer 2

I've done exactly what your describing to great effect across more than 300 locations. I don't think you made the wrong call.

Another thing you could consider that would work well is using MSMQ. In this case, however, you'll either need to write event triggers (COM) or an event queue processing service.

Answer 3

By "web services" I assume you mean an ASMX? I would go with WCF is possible, simply because you lose nothing but gain lots of flexibility. You could, for example, switch from XML-over-HTTP to Binary-over-TCP through a simple config change.

Answer 4

I would suggest to use WCF and use the Net.Tcp binding. It should be efficient enough for 300 clients. For the proxy class issue use the /reference option for the svcutil tool when you generate the proxy. This will allow you to share classes between server and client. I would not use this option if interoperability was a concern but since you stated that you develop both the clietn and the service and all in .Net it is a valid use in your case.

Answer 5

Your distinction between "Web Services" and WCF is a false distinction.

ASMX Web Services is the original .NET SOAP Web Service technology, introduced in .NET 1.0. It has been replaced by WCF, which can everything that ASMX can do, plus a whole lot more (including support for the WS-* standards).

Microsoft now considers ASMX Web Services, and the XML Serializer they're based on, to be "legacy technology". See "Microsoft says: ASMX Web Services are a “Legacy Technology”".

Answer 6

With WCF, since you have control of both sides of the operation, and can share the .dll in which the service contract is defined, you can and perhaps should be using ChannelFactory<IYourServiceContractHere> instead of auto-generating those ugly proxy classes with service references.

Here's the first hit I found on this topic: http://blogs.msdn.com/juveriak/archive/2008/02/03/using-channels-vs-proxies-in-wcf.aspx