SOAP和WebService的那些事

一不小心写了这么多，单独开个帖子吧。

[quote="C_J"]
**但是我想设计那些xml传输格式的委员会不会不懂吧？
所以我觉得WebService设计的协议应该是有他的渊源的，“存在即合理”嘛
不知道andot学长有没有了解过那些渊源呢？不妨给大家讲讲吧。
[/quote]

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

公元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了，但最后所有的活还是要你自己来干。

好了，就先写这么多吧，再长的话，估计人还没读完了就开喷了。哈哈。