在看Web Services（二）Web Services的本质

Web Services是基于XML一种中间件，包括 WSDL，SOAP 和UDDI。
（因为很多原因，UDDI很少被使用）Web Services使用XML对传输的数据进行编码和解码，可以让企业把自己的产品以services的形式发放，而不是软件以软件的形式，从而对服务进行收费。

在这里注意：web services是用XML 实现编码 和解码的。为什么是xml？ 因为其 跨平台性。

当企业的产品以service的形式发布的时候，客户可以在任何平台调用，而不需关心其内部实现。比如，一个在线的计算器，用户调用服务，输入 1 + 1，得到 2，就可以了。

在论坛上，看到了很多人错用了Web Services的技术，或是错用这种概念。

举个例子 Hessian 是不是 Web Services Protocol？
不是 。hessian是一种分布式计算的协议，本质上，一种 RMI；一种轻量级 RMI。 但其不是 Web Services Protocol。
当你在服务端与客户端同时添加了hessian.jar的时候，就把双方平台限定了以hessian为基础。理论上，和 Java RMI 是一致的。

Hessian通过自己定义的序列化方式，在 服务端 与 客户端进行解码。其速度，一定快于基于XML的编码 和解码。

事实上，如果你能同时决定 Services 与 Client的开发，RMI确实是更好的选择，因为，大多数语言的序列化 都比 xml 序列化的效率好很多 。

Web Services的效率问题集中在哪里？
1. HTTP  2. XML 3 SOAP

Web Services说白了就是为了跨平台，如果相同平台又不需要集群，何必要用XML呢？XML是不错，不过在大数据量的时候效率非常低下，所以才有了硬件的XML解析。
java上实现webservices觉得AXIS2不错，相对比较简单。

Web Service的目的是为了把 软件 改成 service。在这个过程中，要解决得一个问题就是 如何跨平台。这个才是选择xml的原因。

但是 xml 也引入了更多的问题。

呵呵,,,,,SOCKET何苦为难SOCKET呢? 都是SOCKET...如果你愿意你完全可以定义自己的SOCKET交互数据格式.

要是跨平台或者是跨区域的话， SOCKET的问题是多多啊。如果要多个系统之间交互， 不敢想象。

SOCKET的问题不多,协议的问题比较多. 要根据实际情况去考虑是否要用WS 因为WS 的短连接机制是后期性能的瓶颈所在,  因为建立连接的时间远远大于你逻辑处理时间. 所以有的时候用SOCKET还是有好处的.