SOAP和WebService的那些事（歷史貼）
阿新 • • 發佈：2019-02-08
一不小心寫了這麼多，單獨開個帖子吧。
C_J 寫道
**但是我想設計那些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了，但最後所有的活還是要你自己來幹。
好了，就先寫這麼多吧，再長的話，估計人還沒讀完了就開噴了。哈哈。
C_J 寫道
**但是我想設計那些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了，但最後所有的活還是要你自己來幹。
好了，就先寫這麼多吧，再長的話，估計人還沒讀完了就開噴了。哈哈。