本文来自互联网
一不小心写了这么多,单独开个帖子吧。
**但是我想设计那些xml传输格式的委员会不会不懂吧?
所以我觉得WebService设计的协议应该是有他的渊源的,“存在即合理”嘛
不知道andot学长有没有了解过那些渊源呢?不妨给大家讲讲吧。
当初对这段历史有过一点研究,不过当初写得关于这部分历史的论文不知道被我丢哪儿去了,下面我用通俗一点的语言来话说一下这段历史吧,因为当初详细到具体人物具体时间的已经记不清了,所以这里写得不够专业,大家就当看个笑话好了。
公元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了,但最后所有的活还是要你自己来干。
好了,就先写这么多吧,再长的话,估计人还没读完了就开喷了。哈哈。
原文链接:http://andot.iteye.com/blog/662787