通信接口是webservice快还是scoket快
webservice和scoket都可以做为通信接口，一个走HTTP访问，一个走TCP协议访问
问1：
通讯速度是webservice快还是scoket快
问2：
并发数量是webservice大还是scoket大
问3：
大数据包是webservice合适还是scoket更合适
以上一个问题15分，先谢谢各位回复，回复得好，还会给贴加分！
------解决方案--------------------
apache的mina2.0对scoket做了封装和实现，据说是高性能，高并发。没在实际项目中使用过，给你提供点参考信息。
------解决方案--------------------
肯定是 Socket 快了！
WebServices 是建立在 HTTP 基础之上的，而 HTTP 是建立在 TCP 基础上的。也就是说 WebServices 在 TCP 基础上包装了两层！
但是，直接使用 TCP Socket 的话速度是快了，但是出错的几率，以及开发难度成数倍地增加了。Socket 通信的话，你还得自己设计通信协议，光这点就很复杂。
------解决方案--------------------
WS封装的层数多点，肯定Socket快。
------解决方案--------------------
问题2和问题3都是和问题1一样，Socket好些。
因为WS需要在HTTP协议上传信息，包的尺寸就会大些。大数据量，这个影响就明显些。
而因为多了些marshal/unmarshal的步骤，所以WS占CPU的资源肯定大些，同硬件配置下自然通量低些。
但使用Socket的确有问题，2楼有说，不重复了。
------解决方案--------------------
学习。
个 人觉得，WS果断比自己写个协议成熟。除非企业要求高。
------解决方案--------------------
超底层越麻烦！
------解决方案--------------------
对于楼主的前两个问题，现在java都有对此非常好的支持与封装，单从这两种技术上来讲速度，以现在的机器硬件可以忽略不计。实际项目中的性能更多的是去关注你的程序的设计架构和稳定性，而不是你的程序在将处理完后的数据交给底层用哪种方式进行网络传输时的性能消耗。
当然如果楼主你们的目标项目是类似于视频系统，会有巨大的网络数据传输，那就另当别论了。但一般的商业项目，只是通信一些商业数据和用户数据的话，很有可能一个网络报文过来你这一个线程需要花费好几秒的时间来做处理，然后不到一秒的时间就从socket或者web service端口将处理后的信息发送出去了(如果网络状况良好的话)。
所以第一个问题，通信速度，底层都是TCP连接，都需要进行三次握手才能建立连接，只要你的网络状况良好，这个性能消耗是不需要上层应用程序去考虑的，否则的话那我们现在用的所有TCP通信的软件岂不是都非常的消耗性能了。
第二个问题，这两种技术都支持多线程并发，这个几乎全部取决于你的多线程架构是否良好，跟底层的关系应该不是很大。顶多在一些比较少见的情况考虑一下直接使用TCP协议和web service在底层上的一些差异。不过对于服务端的ServerSocket，需要考虑是需要进行长连接还是短连接的问题。web service是建立在HTTP基础上的，底层全部都是封装好的，不需要你去考虑底层通信的细节。而且基于HTTP上层，web service本身还有很多种协议可供选择。
第三个问题，大数据包的话，比如说视频网站之类的，具体可以参考下这个领域的一些资料，什么断点续传，P2P协议支持等等，毕竟大多数的J2EE商业领域都还是以传输一些商业数据和用户数据居多。
简单发表了一下个人看法。不过顺带说一句，现在的大趋势已经逐渐走向SOA架构了，所以肯定是web service越来越受欢迎，在网络上跨平台调用你的服务就像你在程序里调用底层封装好的一个API方法一样简单。如果是基于socket，别人想要调用你的服务，还得专门写一个支持你这个socket接口的Adapter。
------解决方案--------------------
------解决方案--------------------
问1：
通讯速度是webservice快还是scoket快
Socket快出很多（不需要解析XML、不需要传递大量重复的XML标记）
问2：
并发数量是webservice大还是scoket大
web service的并发数等于服务器的并发数，可以做服务器集群，Socket集群比较复杂（服务器间通信复杂），
问3：
大数据包是webservice合适还是scoket更合适
大数据包Socket合适些Webservice可以自己制订报文然后压缩传输效率也不错， 或者可以考虑 Tuxedo 、EJB、