Web Service和WCF的到底有什么区别
Web Service是早期的技术实现了，也是soap的东西，采用的主要是http协议，假如是在C#上开发的话，需要寄宿在IIS上来实现。
WCF的话是相对较新的技术，里面的basichttpbinding可以跟以前的ws进行通信，并且集成了大部分的通信协议(几种http协议的实现以及net.Tcp实现、msmq、命名管道等实现)，另外寄宿的宿主可以是命令行控制台、IIS、桌面程序等。
差别的话，感觉有这以下几点[针对C#来说的]。
ws的话，编程模型没有wcf的那么好，具体的实现差别建议百度下，个人觉得wcf比较好。wcf可以用契约的接口方式来进行实现，而ws的话主要是通过继承WebService的类来实现的，方法上添加WebMethod特性，WCF的话是通过服务契约来声明(可以是接口也可以是类对象)
ws的话通用性比较强，跟java等ws也可以进行互相通信，然后假如是wcf发布的服务，除了basicHttpBinding这种绑定之外，其余的几种绑定基本上不能作为互相通信。例如命名管道跟net.Tcp都是，值得说的是这里的net.Tcp跟原生的tcp是不一样的，内部实现上参考tcp的可靠连接机制进行了应用层的一套实现。
另外一点就是服务引用跟web引用上的，这个严格来说不能属于两者的区别，只是.net版本的区别，主要是针对客户端对服务端发布好的服务进行的引用，服务引用生成的时候，会在配置文件上存在一份配置项，可以进行ABC终结点的配置，假如是web引用的话，会在setting中添加上一个硬编码的地址。建议用服务引用。
还有一个就是客户端调用服务端开发的时候，webservice的话，基本上只能通过服务端发布的地址来进行引用[应用的方式可以参考点3]，或者通过服务端提供的wsdl文件来进行引用(该种方式一般比较少，因为需要提供文件，而不是通过公开的方式来进行接口的提供，无法应对服务变更后发布问题，但是确实有这个情况的存在)。而wcf的话，还存在可以通过提供契约文件(就是声明了ServiceContract的那个接口文件)来进行服务的调用。
在接口层面的话，凡是IList<class T>以及IDictionary<class T>这一类的泛型实现都会在进行服务引用的时候，都会转换为数组的，例如void F(IList<int>)会在引用后成为void F(int[])这种方式，而才用点4提供的契约文件的话就能保持方法的原始声明。
个人建议的话，假如是新开发的系统基本上都才用wcf比较好，一个是接口的思想，一个是假如需要转换为其他协议的话可以比较方便，只需要通过配置文件修改下就可以[当前前提是没有用到特定协议的特定属性，例如服务回调，有些协议是不支持双向通信的]。而且也需要考虑发布的服务是否需要公开给别的语言进行通信。
另外楼上说的性能在下降的话，我大概说明下：
基本上针对应用的开发都是基于socket的开发，传统的socket开发的话，是需要自己去实现整个通信框架的，包括多线程处理，IOCP等的实现[基本上.net的异步通信模型在内部实现都会绑定好，IOCP是一个异步模型，自行百度]，二进制流的编码处理[网络传输都是通过二进制的，例如utf8到二进制的转换]，tcp无边界消息的处理[udp的话没有这个，但是包体的大小也是有限制]，通信协议的约定处理[例如ws跟wcf是采用soap这种，各种ws的约定，例如多少个字节表示数据流的长度、数据的检验，还是数据加密位，也包括数据的位移处理]，数据上抛模型跟数据回复模型[接受到数据后是需要上抛给业务层去进行处理的，然后也需要回复给客户端，不过也不一定是这样，看需求]，还有各种针对性的处理，例如客户端socket的保存[有可能对长期不适用的套接字要进行自动断开的业务]。类似wcf这种东西的话，还有序列化跟反序列化的情况[序列化跟反序列化是性能开销比较大的，例如序列化是通过反射来实现的，反射又是跟程序集的元数据有关的，属于运行时行为]，假如是自己实现tcp通信模型，就不一定会有序列化跟反序列化的通信模型了，而且wcf为了让通信跟本地调用那样以及标准的方面，字节流都是比较大的，这里也会增加通信的带宽【好比自定义的协议4个字节的数据包长度+1个字节的加密压缩位+N个数据包位+X个字节的检验位，这种的话实际用到的字节就比较少了，因为在数据包里面，可以会用2个字节表示协议头，例如ox0A表示登录接口，再用4个字节表示登录名，4个字节表示密码等】。以上是简单的对socket跟wcf\ws等协议的差别说明。socket跟wcf\ws对比的话，socket性能是最高的，高并发高响应的时候，这里是有差距的，技术上的话，socket需要更加多的技术支持[开发周期长，对人员要求高]，而wcf在应用层面上基本无难度，就是一些配置，出现问题也大部分可以通过百度来处理。另外一个就是托管语言本身的问题，GC这块的，GC回收的时候，是需要挂起堆栈上的线程的，而且GC的线程优先级比你所能创建的所有线程的优先级都要高，等GC执行完毕的时候才能去执行你的线程，wcf在堆对象上申请的空间也会更加多，自然导致GC会受到的概率也会更加大，这里也会可能导致wcf性能不如socket。基本上来说，C#的类都是引用对象，都是堆申请的，在引用计数超出的时候，都会被下一个GC[]操作去回收，真是个奇葩的事情。
总之，在ws跟wcf之间选择的话，个人觉得优先选择wcf好点。
如果是对性能要求较高[高并发等]，或者是长连接再或者是需要用到UDP这种的话，就基本上无法用wcf跟ws这种了，wcf是没有udp协议的，http协议也只是在tcp协议下的上层协议，底层发送的数据包跟实作是不通的。另外对于长连接，虽然wcf提供了类似回调这种情况机制，只是个人不推荐使用在这种长连接的场合下。
纯手打，哎，晚上睡不着。。。。 楼主采纳了吧
Service是早期的技术实现了，也是soap的东西，采用的主要是http协议，假如是在C#上开发的话，需要寄宿在IIS上来实现。
WCF的话是相对较新的技术，里面的basichttpbinding可以跟以前的ws进行通信，并且集成了大部分的通信协议(几种http协议的实现以及net.Tcp实现、msmq、命名管道等实现)，另外寄宿的宿主可以是命令行控制台、IIS、桌面程序等。
差别的话，感觉有这以下几点[针对C#来说的]。
1.
ws的话，编程模型没有wcf的那么好，具体的实现差别建议百度下，个人觉得wcf比较好。wcf可以用契约的接口方式来进行实现，而ws的话主要是通过继承WebService的类来实现的，方法上添加WebMethod特性，WCF的话是通过服务契约来声明(可以是接口也可以是类对象)
2.
ws的话通用性比较强，跟java等ws也可以进行互相通信，然后假如是wcf发布的服务，除了basicHttpBinding这种绑定之外，其余的几种绑定基本上不能作为互相通信。例如命名管道跟net.Tcp都是，值得说的是这里的net.Tcp跟原生的tcp是不一样的，内部实现上参考tcp的可靠连接机制进行了应用层的一套实现。
3.
另外一点就是服务引用跟web引用上的，这个严格来说不能属于两者的区别，只是.net版本的区别，主要是针对客户端对服务端发布好的服务进行的引用，服务引用生成的时候，会在配置文件上存在一份配置项，可以进行ABC终结点的配置，假如是web引用的话，会在setting中添加上一个硬编码的地址。建议用服务引用。
4.
还有一个就是客户端调用服务端开发的时候，webservice的话，基本上只能通过服务端发布的地址来进行引用[应用的方式可以参考点3]，或者通过服务端提供的wsdl文件来进行引用(该种方式一般比较少，因为需要提供文件，而不是通过公开的方式来进行接口的提供，无法应对服务变更后发布问题，但是确实有这个情况的存在)。而wcf的话，还存在可以通过提供契约文件(就是声明了ServiceContract的那个接口文件)来进行服务的调用。
5.
在接口层面的话，凡是IList<class
T>以及IDictionary<class
T>这一类的泛型实现都会在进行服务引用的时候，都会转换为数组的，例如void
F(IList<int>)会在引用后成为void
F(int[])这种方式，而才用点4提供的契约文件的话就能保持方法的原始声明。
个人建议的话，假如是新开发的系统基本上都才用wcf比较好，一个是接口的思想，一个是假如需要转换为其他协议的话可以比较方便，只需要通过配置文件修改下就可以[当前前提是没有用到特定协议的特定属性，例如服务回调，有些协议是不支持双向通信的]。而且也需要考虑发布的服务是否需要公开给别的语言进行通信。
