关于 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）自动生成客户端。

评论

23 楼 andot 2010-05-06  

miaow 写道

呃，不是“棒杀”，是“捧杀”，请看清楚。
棒杀好难的，捧杀容易得多，如今这市道大家都逆反心理严重
反正我是担心，如果我去给别人讲的时候拿着“快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极左，而二进制又太右派了。哲学并不是不可谈的，哲学本身就是一门技术。

22 楼 miaow 2010-05-06  

呃，不是“棒杀”，是“捧杀”，请看清楚。
棒杀好难的，捧杀容易得多，如今这市道大家都逆反心理严重
反正我是担心，如果我去给别人讲的时候拿着“快1倍”除以“长度一半”得到“4倍效率”，我会被踢出去。
这样对我或者对你都没好处吧。

对PHPRPC比较的意见见前面的帖子。Hprose我都没说过吧。

我的观点，SOAP协议族用XML，XML是现在的样子，与其说是技术原因不如说是哲学原因。
不用现在这种形式的“改进”从XML诞生起就不是问题，根本就是设计哲学造成的。
讲这个其实没太大意思。这就和说html为啥不弄个更高效紧凑的格式一样，谁愿意讨论谁讨论，我觉得没得讨论。

21 楼 andot 2010-05-06  

miaow 写道

再次当作商业用语。
“效率上是PHPRPC的10-15倍，是SOAP效率的进百倍”
对有意义的比较——再次强调是有意义的，不是什么“1000个相同字符串的数组”之类的莫明其妙东西——我没看到有“5到10倍”。

另外对“快1倍”除以“长度一半”得到“4倍效率”表示被你打败了。

要鼓吹一个东西切忌捧杀，“就是吹牛B”可不是什么有利的印象，无论从技术吸引还是商业上都不可取吧。

比如拿我公司说吧。
虽然我不认为有广告中的程度，看起来提升也有一定幅度，特别是有js端，研究乃至用下未尝不可。
但如果拿着你那种比较去找我们老大，估计他直接把我骂出来，原因就是这比较没意义。
这样对你或者对谁有好处呢？给个正常的可以用的比较有什么不好么，你卖的不是电视广告的万能治疗仪啊。

我比较的当然不是“1000个相同字符串的数组”这样的东西，http://code.google.com/p/thrift-protobuf-compare/ 这个项目我想你应该知道吧，我是用这个来做得对比评测。如果你说这个也没有意义的话，那就只能说明这个项目没有意义了。

我即没有吹牛B，也没有棒杀，我只是简单的说出一个事实。这个事实或许让你感觉不可思议，但事实就是事实。要说棒杀的话，也不是我在棒杀SOAP，而是你在棒杀Hprose，因为我有事实根据，而你全凭个人看法。

20 楼 miaow 2010-05-06  

再次当作商业用语。
“效率上是PHPRPC的10-15倍，是SOAP效率的进百倍”
对有意义的比较——再次强调是有意义的，不是什么“1000个相同字符串的数组”之类的莫明其妙东西——我没看到有“5到10倍”。

另外对“快1倍”除以“长度一半”得到“4倍效率”表示被你打败了。

要鼓吹一个东西切忌捧杀，“就是吹牛B”可不是什么有利的印象，无论从技术吸引还是商业上都不可取吧。

比如拿我公司说吧。
虽然我不认为有广告中的程度，看起来提升也有一定幅度，特别是有js端，研究乃至用下未尝不可。
但如果拿着你那种比较去找我们老大，估计他直接把我骂出来，原因就是这比较没意义。
这样对你或者对谁有好处呢？给个正常的可以用的比较有什么不好么，你卖的不是电视广告的万能治疗仪啊。

19 楼 andot 2010-05-05  

miaow 写道

而且实际应用中恐怕更关心的是极端情况的效率，0.5秒改进到0.1秒固然好，但远不如10秒改进到5秒来得有用。
以你写的PHPRPC比较来说，你没做到这点。

窃以为其他传输技术都应该先和把java序列化通过HTTP传输比比，嘿嘿。

你说得没错，PHPRPC的效率确实比SOAP快的不够多，比起Java序列化通过http传输也慢。但是PHPRPC毕竟只是个免费开源的项目。我们现在的商业版Hprose效率上是PHPRPC的10-15倍，是SOAP效率的进百倍。比起Java序列化来也要快1倍，而序列化后的数据长度只有Java序列化后的一半，所以从传输来说就是java序列化通过HTTP传输的4倍效率。

所以跟SOAP比，我们不是把10秒改进到5秒，而是把1个小时改进到少于1分钟。

18 楼 miaow 2010-05-05  

呃，上贴是回复andot，PHPRPC算是andot的“孩子”。

SOAP里面还是要是XML，不过把数据打包成非XML的流再BASE64起来当一个element，这就是自己愿意了。

SOAP解析比较慢是真，不过这是先天的，原因与其说是技术问题不如说是哲学问题。

窃以为其他传输技术都应该先和把java序列化通过HTTP传输比比，嘿嘿。

17 楼 步行者 2010-05-05  

<p>

miaow 写道

SOAP固然envelope可以包非XML数据然则已经用非XML传递再用SOAP不就是脱裤子放气么。 对效率的比较也插几句。我想一个正常的比较应该首要比较一般场景，而不是特殊场景。效率这东西的倍数比较是倒数按概率平均的。而且实际应用中恐怕更关心的是极端情况的效率，0.5秒改进到0.1秒固然好，但远不如10秒改进到5秒来得有用。以你写的PHPRPC比较来说，你没做到这点。你放在前面的差距很大的比较就没什么兴趣看。到不同的字符串的数组和自定义类型的比较才有用处。在这些场景下的优势可不是你号称的数字， “孩子是自己的好”，很正常，但捧杀真的很没意思。

</p>
<p> </p>
<p> 对Web service而言，SOAP封装非XML数据还没见过 </p>
<p>脱裤子放屁的事自然不提倡干 </p>
<p> </p>
<p>效率是比较慢，谁都没否认过 </p>
<p> </p>
<p>“孩子是自己的好”，不觉得WS是谁的孩子，至少不是我的</p>
<p>它是作为一种技术出现的</p>
<p> </p>
<p>捧杀更没必要了，合理地利用各种技术，把它运用到合适的场合才是我们应该做的 </p>
<p> </p>

16 楼 miaow 2010-05-04  

SOAP固然envelope可以包非XML数据
然则已经用非XML传递再用SOAP不就是脱裤子放气么。

对效率的比较也插几句。
我想一个正常的比较应该首要比较一般场景，而不是特殊场景。
效率这东西的倍数比较是倒数按概率平均的。
而且实际应用中恐怕更关心的是极端情况的效率，0.5秒改进到0.1秒固然好，但远不如10秒改进到5秒来得有用。
以你写的PHPRPC比较来说，你没做到这点。
你放在前面的差距很大的比较就没什么兴趣看。到不同的字符串的数组和自定义类型的比较才有用处。在这些场景下的优势可不是你号称的数字，
“孩子是自己的好”，很正常，但捧杀真的很没意思。

15 楼 andot 2010-05-04  

<div class="quote_title">步行者 写道</div>
<div class="quote_div">
<p>

andot 写道

SOAP速度慢性能差，这点是公认的，是不可忽略的事实。确实，SOAP就是慢在了XML上。现在高效的跨平台、跨语言、可互操作的RPC确实都已经抛弃了XML，性能上可以达到SOAP的百倍，使用上也比SOAP容易的多。更何况现在用SOAP的人大部分都在误用，不是用SOAP传递对象，而是用SOAP传递XML，也就是用XML包装XML，所以让本来就慢的SOAP加倍的慢。而且用SOAP传递的XML都是自定义的格式，没有任何标准，所以针对每个数据都要做单独解析，因此把原本的跨平台、跨语言、可互操作也丧失了。

</p>
<p> </p>
<p>老帖子又被翻出来 </p>
<p>SOAP作为一种应用层之上的传输协议确实比较慢</p>
<p>慢在了XML和SOAP封装上</p>
<p> </p>
<p><span style="color: #ff0000;">而且用SOAP传递的XML都是自定义的格式，没有任何标准，所以针对每个数据都要做单独解析，因此把原本的跨平台、跨语言、可互操作也丧失了</span></p>
<p> </p>
<p><span style="color: #000000;">这句话不能认同，</span><span style="color: #000000;">SOAP有标准，SOAP传输的XML有格式，数据不需要单独解析</span></p>
<p>1） SOAP的标准自然是SOAP标准</p>
<p>2） SOAP传输的XML格式是在WSDL里定义的（XMLSchema）</p>
<p>3） 很多工具、框架都支持根据WSDL自动生成Web Service 客户端，SOAP及XML数据可自动解析。</p>
<p> </p>
<p><span style="color: #000000;">跨平台、跨语言、可互操作 是建立在Web Service相关协议规范的开放性上的</span></p>
<p> </p>
</div>
<p>你误会我的意思了，你标记的那段红字是针对我说的“<span style="color: #ff0000;">更何况现在用SOAP的人大部分都在误用，不是用SOAP传递对象，而是用SOAP传递XML，也就是用XML包装XML</span>”这句话的。不是针对SOAP本身的。</p>
<p> </p>

14 楼 步行者 2010-05-03  

<p>

andot 写道

SOAP速度慢性能差，这点是公认的，是不可忽略的事实。确实，SOAP就是慢在了XML上。现在高效的跨平台、跨语言、可互操作的RPC确实都已经抛弃了XML，性能上可以达到SOAP的百倍，使用上也比SOAP容易的多。更何况现在用SOAP的人大部分都在误用，不是用SOAP传递对象，而是用SOAP传递XML，也就是用XML包装XML，所以让本来就慢的SOAP加倍的慢。而且用SOAP传递的XML都是自定义的格式，没有任何标准，所以针对每个数据都要做单独解析，因此把原本的跨平台、跨语言、可互操作也丧失了。

</p>
<p> </p>
<p>老帖子又被翻出来 </p>
<p>SOAP作为一种应用层之上的传输协议确实比较慢</p>
<p>慢在了XML和SOAP封装上</p>
<p> </p>
<p><span style="color: #ff0000;">而且用SOAP传递的XML都是自定义的格式，没有任何标准，所以针对每个数据都要做单独解析，因此把原本的跨平台、跨语言、可互操作也丧失了</span></p>
<p> </p>
<p><span style="color: #000000;">这句话不能认同，</span><span style="color: #000000;">SOAP有标准，SOAP传输的XML有格式，数据不需要单独解析</span></p>
<p>1） SOAP的标准自然是SOAP标准</p>
<p>2） SOAP传输的XML格式是在WSDL里定义的（XMLSchema）</p>
<p>3） 很多工具、框架都支持根据WSDL自动生成Web Service 客户端，SOAP及XML数据可自动解析。</p>
<p> </p>
<p><span style="color: #000000;">跨平台、跨语言、可互操作 是建立在Web Service相关协议规范的开放性上的</span></p>
<p> </p>

13 楼 itlangqun 2010-05-01  

楼主总结得通俗，很不错，赞一个！！！

12 楼 miaow 2010-05-01  

世界的ESB都已经抛弃了SOAP...

SOAP信封里不装XML...

没有标准...

11 楼 andot 2010-04-30  

SOAP速度慢性能差，这点是公认的，是不可忽略的事实。确实，SOAP就是慢在了XML上。现在高效的跨平台、跨语言、可互操作的RPC确实都已经抛弃了XML，性能上可以达到SOAP的百倍，使用上也比SOAP容易的多。
更何况现在用SOAP的人大部分都在误用，不是用SOAP传递对象，而是用SOAP传递XML，也就是用XML包装XML，所以让本来就慢的SOAP加倍的慢。而且用SOAP传递的XML都是自定义的格式，没有任何标准，所以针对每个数据都要做单独解析，因此把原本的跨平台、跨语言、可互操作也丧失了。

10 楼 miaow 2010-04-30  

SOAP的那点代价可以忽略吧，除非打算连XML都不用，要不然看不出SOAP费了啥。

至于“最慢最低效”，请明示。怎么觉得这话这么奇怪呢。

9 楼 andot 2010-04-29  

并不是只有基于SOAP的WebService可以跨平台，跨语言，可互操作。基于SOAP的WebService只是最慢最低效的一种，并且还向melin说的那样总是被当成socket来用，使原本的低效更加低效，而且最后连跨平台，跨语言，互操作的能力都丧失了。WebService的还是非SOAP的轻量级的好。

8 楼 kimmking 2010-04-29  

webservice是一种rpc
rmi也是

7 楼 抢街饭 2010-04-29  

由于项目 要接触这东西 也只是了解概念 疯狂学习中

6 楼 visitor 2009-06-18  

Saito 写道

  Web Service也分广义跟狭义。。 基于SOAP的只能算是Web Service的一种实现方式吧。。

  我觉得Web Service就是通过网络提供服务。 我用RMI可以做到。 Rest也可以做到。phprpc也可以做到。 我只是去提供服务。 没得非要用到重量级的标准。无论是axis还是axis2还是cxf。。其实都还算挺麻烦的。 不过在多语言环境下，基于SOAP的Web Service也还是有优势的。。

写一个 SOCKET Server 也可以实现通过网络提供服务，
但这不是 Web Service 的主要目的，
跨平台，跨语言，可互操作才是Web service的主要目的。

5 楼 步行者 2009-06-18  

Saito 写道

   学院派的paper来制定标准。什么Soap  什么 wsdl。。  外国的开源社区。大牛们跟进来实现框架。什么Axis。 CXF。  剩下我们这些人来玩别人玩剩下的。

   如果连别人玩剩下的还没个选择权的话。那还是别玩了。玩也得找个好玩的玩。是吧？

让时间和市场来考验它们吧 ！
有些事情身不由己，如果大家都玩，那你不玩也得玩。。

melin 写道

在企业应用中，好多人只了解web service这个概念。把它当做socket来使用了。浪费....

把它当做socket来使用确实浪费了，
就像把衣服当布料使，再做成衣服，没必要绕这么大的弯。。
好像很少有人这么做吧。。

4 楼 melin 2009-06-18  

在企业应用中，好多人只了解web service这个概念。把它当做socket来使用了。浪费....