Meng Yan ( 孟岩 )’s Weblog

前一段，Blogsphere里面关于WebOS的大讨论甚是激烈，如果说Web2.0的时代，整个Web将会是一个大大的WebOS的话，将各个应用和服务联系在一起的就是两个东西：

• RSS
• Web Service

以前RSS说的太多了，今天就来说说Web Service。Mac OS最新的Tiger里面的Dashboard，里面的每个小Widget都是由简单的HTML、CSS以及Web Service组成的，你可以用这些Widget来查询股票，天气，以及其它很多事情。这些Widget的核心组件，就是调用外部的Web Service。我以前曾经说过的Google IG、Live.com中的Gadget，也都是这个道理。

说到Web Service，就不能不说到RPC（远程系统调用）。所谓的远程，包括进程外，甚至本机外，经典的RPC协议包括DCOM、CORBA以及ICE等等。我觉得，对于RPC来说，最重要的就是两点：

• 将过程调用的参数和返回值序列化（Serizialize）成一系列的数据 - marshalling，中文翻译成“列集”这个怪怪的名字；
• 用某种方式来传递这种数据。对于进程外RPC来说，可以采用共享内存、管道等等。而不同机器之间，则多是用专署协议了，比如DCOM和CORBA，现在有更轻量级的ICE。

Web Service解决以上两个问题的办法是：

• 采用XML来进行数据的Marshalling；
• 采用HTTP来进行数据的传递（SOAP的新标准中也支持了其它协议，比如SMTP）；

记着2000年我刚刚接触Web Service的时候，对采用HTTP来进行数据传输这点很是不以为然，觉得穿透防火墙这些Feature绝对是宣传上的噱头。那时的自己还醉心于对桌面平台的COM、DCOM以及CORBA的研究。现在我慢慢认识到，采用XML（明文、可读）、HTTP（最常用的网络协议），绝对是Web Service得以成功的两个重要的因素。

现在比较流行流行的Web Service主要有三种，分别来说说：

1）SOAP

SOAP，全名是Simple Object Access Protocol，是Microsoft提交给W3C的Web Service协议。我觉得SOAP的两个最大的好处是：

• 协议的可扩展性（Extension Mechanism）
• 良好的工具支持

SOAP的消息称为一个SOAP Envelope，包括SOAP Header和SOAP BODY。其中，SOAP Header可以方便的插入各种其它消息来扩充Web Service的功能，比如Security（采用证书访问Web Service），SOAP BODY则是具体的消息正文，也就是Marshall后的信息。

SOAP调用的时候，也就是向一个URL（比如http://ws.invesbot.com/stockquotes.asmx?WSDL）发送HTTP Post报文，调用方法的名字在HTTP Request Header SOAP-Action中给出，接下来就是SOAP Envelope了。

服务端接到请求，执行计算，将返回结果Marshall成XML，用HTTP返回给客户端。

SOAP的工具支持非常好，比如在.NET里，可以用WSDL.exe非常方便的为一个Web Service生成本地Proxy（Proxy模式），这样，你的程序就像调用本地API一样了，而由Framework为你完成Marshall和传送的工作。

2）XMLRPC

XMLRPC ，我记着看过一段Don Box的采访，他说当时Microsoft费了7年的时间（大概，记不清楚了）才成功的把SOAP提交给W3C，而Dave Winer（眼熟吧，RSS’s Father）借鉴SOAP实现了一个更轻量级的协议，那就是XMLRPC。以前曾经大概看过XMLRPC，XMLRPC就是SOAP的简化和改进，比如说：

• Marshall类型的支持有限
• 取消HTTP Header中的SOAP Action，而将Method Name也放到XMLRPC的Body中
• 传送的XML信息中没有Header，只有Body。

XMLRPC相比于SOAP最大的优势就是它的简单，弱点就是扩展性弱，另外，工具支持也不如SOAP那般正规，感觉起来，一个像正规军，一个像游击队。不过，游击队才有作战灵活的特点 :P。

XMLRPC在社区中非常流行，我这篇Blog是在Writely写的，通过WordPress的XMLRPC接口发布到我的Blog上。

3）REST

REST - Representational State Transfer, 是Roy Fielding的博士论文中提出的概念，其实，与其说REST是一种Web Service协议，不如说REST是一种Web based软件架构，一种基于Resource State的服务访问架构。

通俗的将，可以用你访问我的Blog的过程来描述REST的工作流程。当你访问我的Blog首页，其实就是对我的Blog的一个资源访问，那么Web Server会将这个资源的Representation返回给你，也就是我的Blog的首页的HTML。当你点击了这个HTML中的一个link，比如某篇Blog，你实际上就又对另一个资源发生了请求，Web Server会将新的资源Representation以HTML的形式发送给你。

REST的参数传递是采用URL Query，而返回值就是XML了。

我曾经看过一个人对REST和SOAP的解释，我觉得很对，SOAP是面向活动，而REST是面向资源的。

Build一个Web Service，in SOAP way还是in REST way还是有很大的不同的。

比如说，要实现一个世界杯赛程、赛果、球员评分查询的这样一个简单的Web Service，如果用SOAP的话，我们可以生成一个WSDL：

http://www.mengyan.org/worldcup2006/?WSDL

它包含很多方法，比如GetMatchResult, GetPlayerScore, GetFixture，客户端通过调用这些Web Method来获得相应的数据。

如果用REST的方法来构架，就得先分析系统中都有那些资源，每一个资源有一个URL，比如：

http://www.mengyan.org/worldcup2006/fixture/?team=Brazil

http://www.mengyan.org/worldcup2006/match/?id=1

http://www.mengyan.org/worldcup2006/player/?name=Beckham

每种资源都是一个URL，然后利用URL Path或者Query来实现参数的传递，Response则是这个资源的一个表示形式。

当然，这些只是逻辑上的URL，具体的实现是采用URL Rewrite还是其它就可以你的具体设计了。

万事没有绝对，你也可以用其它方法设计REST Web Service。比如Flickr，它的Rest Service都是如下样子：

http://www.flickr.com/services/rest/?method=flickr.test.echo&name=value

也就是说，整个Service是一个资源，method变成了参数，用Method来标明不同的方法调用。我觉得，Flickr的REST Service其实还是采用传统的SOAP思想考虑的，只不过用了REST来实现。不能称作Thinking in REST way :-)。

Ok，就说到这里吧。最后别忘了，和本机的Function Call相比，Web Service还是有很多需要注意的地方，最重要的两点就是Performance和Security。有很多需要注意的地方，这些说起来就太多了，而我也还有很多需要学习的地方，就简单举两个例子：

• 减少方法调用的次数
• Message-Based Programming
• 利用Cache

我一直在想，如果有一天，我在Debug的时候，Stack Trace是一层层、一个个的Web Service，是不是很有意思？

Popularity: 42%