关于 Web Service 的一些理解关于 Web Service 的一些总结，一些理解1，什么是 Web Service ??? Web Service
关于 Web Service 的一些理解
关于 Web Service 的一些总结，一些理解
1，什么是 Web Service ?
?? Web Service 就是一个网络组件（一个可以通过网络访问的程序）。
?? 它有一个或多个端口（Port），这些端口用于接收客户端的请求，并返回响应
?? 请求和响应的 都是一种基于XML的消息。
?? 不过这种消息遵循特定的格式（SOAP）。
2，怎样调用 Web Service？
?? 可能这样说不太准确，应该是“怎样调用Web Service中定义的操作”
?? 每个Web Service 都有一个描述文件（WSDL），
?? 它描述 一个 Web Service 的如下方面：
?? （1）服务的端口（接收SOAP消息的端口）
?? （2）服务提供的操作
?? （3）操作的输入输出格式的定义（通过XMLSchema定义输入输出格式）
?? ?有了Web Service 的描述文件（WSDL），我们就知道怎样调用这个Web Service 中定义的操作了。
?? （1）通过服务提供的操作找到你想调用的操作
?? （2）找到这个操作的输入格式的定义（XMLSchema），按照这种输入格式构造一个SOAP消息
?? （3）将这个SOAP消息发送到服务的指定端口
?? （4）准备接收一个从Web Service服务器返回的 SOAP 响应吧 !
3，Web Service服务器
?? 一个Web Service服务器，本质上和一个Web服务器是相同的。
?? 它主要做下面这些事：?
--> 监听网络端口（监听服务端口）?
--> 接收客户端请求（接收SOAP请求）?
--> 解析客户端请求（解析SOAP消息，将SOAP消息转换为数据对象）
--> 调用业务逻辑 （调用Web Service实现类的特定操作，参数是由SOAP消息??
????? 转换而来的数据对象）
--> 生成响应 （将返回值转换为SOAP消息）
--> 返回响应 （返回SOAP响应）
?
4，Web Service客户端
?? 一个Web Service客户端，顾名思义是和一个Web Service服务器进行交互。
??下面是一个Web Service客户端调用Web Service的基本过程。
--> 构造SOAP请求消息（将本地数据对象转换为SOAP消息）?
--> 发送SOAP消息到Web Service服务器的指定端口
--> 接收SOAP响应消息 ?
--> 将SOAP响应消息转换为本地数据对象
?
?? ?其实大部分Web Service客户端 都不需要我们来编写，很多Web Service框架
都支持由 Web Service 的描述文件（WSDL）自动生成客户端。
反正我是担心，如果我去给别人讲的时候拿着“快1倍”除以“长度一半”得到“4倍效率”，我会被踢出去。
这样对我或者对你都没好处吧。
对PHPRPC比较的意见见前面的帖子。Hprose我都没说过吧。
我的观点，SOAP协议族用XML，XML是现在的样子，与其说是技术原因不如说是哲学原因。
不用现在这种形式的“改进”从XML诞生起就不是问题，根本就是设计哲学造成的。
讲这个其实没太大意思。这就和说html为啥不弄个更高效紧凑的格式一样，谁愿意讨论谁讨论，我觉得没得讨论。
反正我是担心，如果我去给别人讲的时候拿着“快1倍”除以“长度一半”得到“4倍效率”，我会被踢出去。
这样对我或者对你都没好处吧。
对PHPRPC比较的意见见前面的帖子。Hprose我都没说过吧。
我的观点，SOAP协议族用XML，XML是现在的样子，与其说是技术原因不如说是哲学原因。
不用现在这种形式的“改进”从XML诞生起就不是问题，根本就是设计哲学造成的。
讲这个其实没太大意思。这就和说html为啥不弄个更高效紧凑的格式一样，谁愿意讨论谁讨论，我觉得没得讨论。
你说得也有道理，所以这个速度上快多少倍，我们实际上都是让用户自己去试的，上面我跟你说得那些快多少倍也是用户自己测出来的结果。所以要说捧，也不是我自己在捧，是用户在捧。
另外，你说HTML为啥不弄成紧凑高效的，这个问题其实很简单，HTML就是让人写的文档语言，一个让人写的搞得格式紧凑自然会让用户觉得很麻烦，HTML的规范甚至比XML还要宽松，比如大小写什么得都没有特别要求，标签交叉上也没有XML那么多限制。而XML的要求则比HTML严格多了，所以当HTML要用XML规范化的时候（XHTML），虽然叫好声一片，但真正完全XML化的HTML页面却不多见，尽管大部分页面已经被标记为XHTML了，但内容仍然是HTML的格式。
XML也是一种文档语言，他设计出来最初的目的跟HTML类似，也是为了让人易写易读的，但它是可扩展的，而不像HTML仅用于网页内容描述。所以XML最适用于那些用于既让人来读写，也让机器来读写，又不关心效率的场合，比如作为配置文件，用于记录日志等。但是用于远程调用的话，选择XML就是个激进的选择了。远程调用中数据更多的是交给机器来进行读写，而且对效率要求较高，而让人读写的情况并不多。即使需要人来读，也仅是存在于调试阶段。所以选择XML就有些舍本逐末了。而格式更紧凑的半文本结构在这里则更好过XML这种纯文本结构。半文本结构的特定是，机器读写高效，接近甚至超过二进制数据的生成和解析效率，结构紧凑，数据量上远远小于XML，接近甚至小于二进制数据表示方式。在可读性上具有与纯文本类似的可读性，完全可以满足调试阶段的人类读写要求，而不像二进制数据那样完全不可读。所以在远程调用中，选择半文本结构是更好的设计哲学。XML极左，而二进制又太右派了。哲学并不是不可谈的，哲学本身就是一门技术。
