webservice和scoket比较分析

问1：
通讯速度是webservice快还是scoket快

Socket快出很多（不需要解析XML、不需要传递大量重复的XML标记）
问2：
并发数量是webservice大还是scoket大
web?service的并发数等于服务器的并发数，可以做服务器集群，Socket集群比较复杂（服务器间通信复杂），
问3：
大数据包是webservice合适还是scoket更合适
大数据包Socket合适些Webservice可以自己制订报文然后压缩传输效率也不错，??或者可以考虑?Tuxedo?、EJB、

肯定是?Socket?快了！

但是，直接使用?TCP ，Socket?的话速度是快了，但是出错的几率，以及开发难度成数倍地增加了。Socket?通信的话，你还得自己设计通信协议，光这点就很复杂。

web?service相对开发简单，不需要制定传输协议，减少很多Socket需要的联调时间，另外Socket也有相应框架Apache?Mina、Nety(不知道拼错没)...效率肯定Sokect会高出很多，而且做集群灵活性比较高。

对于楼主的前两个问题，现在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。