webservice 杂谈

当初对这段历史有过一点研究，不过当初写得关于这部分历史的论文不知道被我丢哪儿去了，下面我用通俗一点的语言来话说一下这段历史吧，因为当初详细到具体人物具体时间的已经记不清了，所以这里写得不够专业，大家就当看个笑话好了。

公元2000年前，互联网发展非常迅速，HTML得到了越来越多的应用，但专家们对HTML并不满意，因为它只是一个用于描述网页的文档语言，只是一个SGML在具体方面（Web上）的一个应用的实现，HTML不具有良好的扩展性，而SGML虽然无比强大，但又太过复杂，以至于甚至没有人知道它是个什么东西。

在这种情况下，专家们开始设计一种比SGML要简单的多，还要比HTML具有更好扩展性的文档标记语言，于是XML诞生了。

所以，XML并不是为WebService而诞生的。

XML诞生之后，得到了业界的热捧，当时街头巷尾都在传扬XML的伟大和无所不能，随便一个计算机书店里你都能看到半个书架的关于XML的著作。

XML确实是很有用的东西，后来的事实也证明了这点，比如SVG、MathML、GML等都是XML的非常棒的具体应用。

但是当一个东西被炒的过热的时候，人们再选择它就不再单单是处于技术原因了，而是希望借助它的热力把自己的产品也捧上去。

这一点微软就做的很好，1998年，一个叫UserLand的小公司的一位牛人Dave Winer设计了XML-RPC,因为跟XML沾边，所以立刻就被微软看好了。这个XML-RPC最初其实就叫做SOAP，直到被微软看上并派人去一起合作。很快他们完成了最早的实现，并被改名为XML-RPC。

好了现在实现上没有问题了，但要推广，还是标准化一下比较好，于是微软把IBM, Oracle, Sun, Apple, Netscape等找来说我们一起把它标准化吧，这样我们大家就一起可以用它赚钱了，于是SOAP就这样形成了。

但大家知道，这些大厂商们制定标准那是各怀鬼胎啊，微软怎么可能把便宜就这么好心的让给其他人分享呢？所以SOAP标准里面除了一丁点的通用部分外，还包括允许私有扩展的内容。而且微软在这个制定过程中，已经开始做这部分内容了，所以SOAP刚刚出来，微软就抢先其他人推出了成熟的WebService产品。这就是后来大家在.NET 1.0中看到的WebService。

当时你会看到微软在宣传WebService时，最喜欢举的例子就是WebService可以传输.NET的数据集（DataSet)，这是一个看似非常强大的功能，但它也是微软对用户的最大误导，微软一边告诉你SOAP是跨平台、跨语言的国际标准，一边大讲特讲用WebService可以方便的传输.NET数据集，但是有一点微软就是不提，那就是这个数据集虽然使用WebService可以传输，但它并不是跨平台跨语言的，你只能在微软的.NET平台上来使用。能跨平台、跨语言的部分仅仅是一些简单类型以及这些类型的一些集合类型。

但微软为什么要这样宣传WebService呢？目的很明显，它就是让你以为用了WebService之后不用再担心跨语言跨平台的问题，但一旦你用它来传输了数据集，事情就不再是这样了，你已经被.NET平台给绑架了，从此你的WebService只能被.NET这一个平台独享，所以这是微软的一个阴谋。直到你真正开始做跨语言应用的时候才会发现的阴谋。

因为微软是最早实现WebService的，其它厂商比起它来慢了不止一点点。所以当WebService被普及开之后，IBM等厂商并没有占到什么便宜，所以，微软以外的厂商不干了，于是SOAP开始了它的重新修订。所以SOAP的修订并不仅仅是处于技术上的目的，更多的是各大厂商对利益的博弈。因此SOAP的每个修订版本跟前一个版本在兼容性上都很不好，甚至新版本会推荐你把旧版本中的特性完全放弃，原因就是旧版本对微软太有利了。

经过几番博弈之后，各大厂商的利益总算是得到了平衡，SOAP也就变成了今天的这般模样，那就是IBM推荐的，你们不要再传对象了，你们直接传XML吧。所以现在在IBM支持下的那些开源实现都是大力支持直接传XML的WebService的。

但它真正解决用户的问题了吗？没有，它非但没有解决用户的问题，而且还饶了一个大圈子最后把如何解决问题推给了用户。

但是对于IBM这些大厂商来说他们的目的已经达到了，经过这么长时间的洗脑，用户被一个不知道为什么这样做却不得不这样照着做的SOAP标准给绑架了，因为它被称为标准，虽然它实际上并不能解决你的问题，但因为你自己确实可以通过一些自己的方法来解决它所带来的问题，以至于让你相信这些问题是它帮你解决的，因为它的权威摆在那里，所以你几乎从来不怀疑它只是给你带来了问题让你解决，而不是帮你解决已有的问题。

但对于制定这个标准的大厂商们来说，他们的钱已经赚到了，所以不管SOAP和WebService本身究竟多差劲，他们是不会在意的，对他们来说赚钱的东西就是好东西，更何况将你绑架在了他们自己的平台和语言上赚钱，还能让你相信是跨平台的跨语言的呢。

直到现在微软在推的WebService仍然跟IBM资助的那些开源的Java实现的WebService不能真正的做到互通，不信你就传个数据集试试，你甚至连泛型容器都不能互传，哦～确切的说，你连非泛型的容器（比如.NET中的ArrayList)都不能互传，为什么？因为在.NET中序列化ArrayList到SOAP时，它是被序列化为名称空间是http://schemas.microsoft.com/clr/ns/System.Collections的绑定于.NET平台的特殊类型的数据啦。这种情况下，你怎么可能像SOAP描述的那样跨语言传输真正的对象？

所以，基本上现在用SOAP的人都在用它传输字符串。

好了，现在大家应该明白了，SOAP其实是一个被微软和IBM这样的大厂商绑架了的标准，在这些大厂商自己的实现中包含了太多的私有东西，这样就造成了技术壁垒，你不可能真正的实现它所描述的跨语言跨平台特性，另外SOAP和WebService标准本身就非常复杂，WebService有一大串的标准，就连微软自己都无力完全实现这些，更何况那些没有大厂商支持的语言呢，其它的语言有些标称自己支持WebService了，实际上呢，支持的仅仅是最基本的部分而已，而大部分标准中的内容根本就没有实现，甚至有些语言提供的仅仅是XML解析工具，就标称已经支持WebService了，但最后所有的活还是要你自己来干

HTML就是让人写的文档语言，一个让人写的搞得格式紧凑自然会让用户觉得很麻烦，HTML的规范甚至比XML还要宽松，比如大小写什么得都没有特别要求，标签交叉上也没有XML那么多限制。而XML的要求则比HTML严格多了，所以当HTML要用XML规范化的时候（XHTML），虽然叫好声一片，但真正完全XML化的HTML页面却不多见，尽管大部分页面已经被标记为XHTML了，但内容仍然是HTML的格式。

XML也是一种文档语言，他设计出来最初的目的跟HTML类似，也是为了让人易写易读的，但它是可扩展的，而不像HTML仅用于网页内容描述。所以XML最适用于那些用于既让人来读写，也让机器来读写，又不关心效率的场合，比如作为配置文件，用于记录日志等。但是用于远程调用的话，选择XML就是个激进的选择了。远程调用中数据更多的是交给机器来进行读写，而且对效率要求较高，而让人读写的情况并不多。即使需要人来读，也仅是存在于调试阶段。所以选择XML就有些舍本逐末了。而格式更紧凑的半文本结构在这里则更好过XML这种纯文本结构。半文本结构的特定是，机器读写高效，接近甚至超过二进制数据的生成和解析效率，结构紧凑，数据量上远远小于XML，接近甚至小于二进制数据表示方式。在可读性上具有与纯文本类似的可读性，完全可以满足调试阶段的人类读写要求，而不像二进制数据那样完全不可读。

以上转自http://www.iteye.com/topic/662787，http://www.iteye.com/topic/410195?page=3 ,andot的帖子，在此表示感谢

--------------------------------------------------------------------------------------——————————
WebService也分广义和狭义之分。
广义来说，只要提供网络服务、远程调用就是webService.
狭义的，就是基于soap协议，xml、WSDL、UDDI的标准webService.

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