SOA和Web Service分道揚鑣(SOA是關於業務流程的,而不是集成的--即:WEB S...

可能在市場上圍繞着面向對象的架構(service-oriented architecture，SOA)誤解最深的是SOA和Web Service是同一個概念。這些觀點致使了多家廠商的標準的努力並最終確立了爲Web Service提供基礎的規範的核心：

可能在市場上圍繞着面向對象的架構(service-oriented architecture，SOA)誤解最深的是SOA和web Service是同一個概念。這個誤解傳播的很廣，影響了架構師和開發人員、諮詢師和廠商等。可是儘管ZapThink不斷的在平常的事務上澄清不少問題，這種誤解仍是存在於一些匆匆檢查中沒法輕易辨別的細微之處。結果，僅僅站起來喊一下「SOA是組織IT資源更好的知足業務不斷變化的需求的一種方法!」「web Service是基於標準的、協議化的軟件功能和數據的接口!」是遠遠不夠的。畢竟，若是僅僅是關於不一樣術語的各自定義的問題，那麼這種誤解早就消失了。因此，爲何這麼基礎的誤解至今還困擾着咱們?咱們該作些什麼來解決這個問題並最終取得進步呢?對這兩個相關、可是各自不一樣的概念的歷史進行簡要回顧將有助於澄清這個差別。

最初SOA和web Service是捆綁在一塊兒的

代表SOA和web Service是不一樣的概念的第一個證據是SOA在web Service出現以前早已存在。早在1990年，像公用對象請求代管者體系結構(Common Object Request Broker Architecture，簡寫爲CORBA)和微軟的分佈式組件模型(Distributed Component Object Model，縮寫爲DCOM)的分佈式計算方法都是以一種協議的方法抽象軟件功能的架構方法，可以提供必定程度的鬆耦合性，提供比使用其餘方法的緊耦合性接口的架構更大的靈活性——換句話說，它們是面向服務的。雖然CORBA和DCOM都在市場上得到了必定的成功，可是DCOM明顯就是一家廠商的架構，而COBRA雖然表面上是廠商獨立的，可是在實施中仍是和廠商有關，由於CORBA不一樣的廠商的實現被證實是互相不兼容的。

這個故事還算不上有趣，直到1990年代的後期，當時一些廠商達成了兩點基本的共識：第一，SOA的方法不會提供真正的靈活性，除非它是與實現獨立的，第二，相對較新的可擴展標記語言(eXtensible Markup Language，XML)會成爲理想的消息協議，即便它的最初的目的是做爲文檔標記語言。這些觀點致使了多家廠商的標準的努力並最終確立了爲web Service提供基礎的規範的核心：web Service描述語言(web Services Description Language，WSDL)，統一描述、發現和集成協議(Universal Description, Discovery, and Integration，UDDI)和簡單對象訪問協議(Simple Object Access Protocol，SOAP)( 如今已經不是這個的縮寫了, 由於訪問對象已經沒有意義)。

SOA由三個標準支持的「發現-綁定-發佈」三角的早期工做主要集中在商業對商業(business-to-business，簡稱B2B)的應用上，同時還有全球的「green pages」目錄，它容許對整個Internet上商業web Service的自動發現和綁定。問題是，沒有人願意按照這樣的方式來作業務。實際上從黃頁上選擇一個水管工都十分冒險，因此還有誰會自動化流程，在系統之間增長任意的交互?結果，做爲.com繁榮期末尾的「web 1.0」B2B電子商場趨勢的失敗的一小部分，這個早期的SOA的B2B計劃失敗了。

web Service唱主角

雖然瘋狂的.com的終結和隨之而來的IT的衰退打擊了不少標準的制訂工做，可是咱們將2002-2003期間稱爲web Service的黃金時代。廠商們意識到在艱難時期惟一有但願產生業務的故事就是節約成本的方案，而且web Service有一個偉大的特色：下降集成的成本。從私有的接口轉到基於標準的接口，想一想你能夠節約多少錢!雖然那些日子裏標準還遠不是成熟，可是至少商業案例對於投資者而言已經足夠美妙了，這些投資者都在泡沫破滅的回憶中戰戰兢兢而且尋找新的機會。就這樣，web Service的市場誕生了。

固然，憑藉着早期對於web Service技術和趨勢、XML&web Service安全、面向服務的管理和測試web Service等報道，ZapThink又一次領導了web Service的潮流。而且，早在2002年二月當咱們在《XMLand web ServicesUnleashed》書中討論架構的時候，咱們建議那時的廠商不要談到SOA，由於市場尚未準備好SOA所表明的更加複雜、以商業爲中心的邏輯。相反，這些報道以web Service架構爲中心，該架構是基於標準的集成方法。

而且，回顧2002年的時候，咱們意識到在那一年6月的面向服務的集成報告中有一個在今天來看都是預言性的一個基本的真理：雖然web Service單獨就能夠下降集成的成本，只有轉移到SOA方能下降組織機構的業務變化的長期成本。換句話說，web Service讓你得到了去舞會的入場卷，可是你還要學會跳舞。

web Service黃金時代的結束

隨着SOA的討論開始增長，web Service則進入了挑戰的青春期。支持WSDL、UDDI和SOAP並不能保證互操做，而且也不足以標準化隨機的系統對系統之間的交互的複雜性。這些限制致使了兩方面的努力：web Service互操做組織(web Services Interoperability Organization，縮寫WS-I)，它致力於提供標準的互操做，和其餘各類後續的標準，其中不少都被用術語WS-*來歸納(發「WS star」的音，*在老的Unix中表示「一切」)。這些努力，固然，會花費時間，而且隨着各類標準的正文都是由各類廠商用本身的計劃來填充的，整個狀況就開始變的複雜的、政治的泥潭，而這些並無給試圖下降集成成本的組織結構提供些許的真正的互操做。結果，web Service並無達到原有的指望，而如今也愈來愈成爲SOA故事的邊緣部分了。

事實上，當許多IT產品廠商看到SOA井中的黃金以後，web Service的花車慢慢的沒落了。這些廠商開始拍着他們產品上的web Service接口，叫嚷着這是面向服務的，這種方法無異於給小豬畫上口紅。事實上，對應用或者數據庫的web Service接口，或者是在私有消息中間件上的web Service適配器，都不算SOA的。

同時，在咱們的SOA工具和最佳實踐以及面向服務的流程報道中，ZapThink指出以商業流程爲中心的SOA是企業架構，而且在2004年，咱們開始建議廠商的廣告要集中在SOA上而不是web Service。咱們爲現在的企業所繪製的圖景要比直接採起web Service更加具備挑戰性，由於SOA包括對業務如何從不少不一樣的方面來利用IT的從新思考。web Service仍然是故事中的一部分，可是現在很清楚的是web Service不是SOA的核心，而且更進一步，SOA並不須要web Service。

ZapThink的行動

所以，2007年的故事是將web Service從SOA中分離。咱們在SOA環境中所談到的服務要比開發人員用來支持組織機構的互操做要求的某個接口標準具備更高的抽象級別。不少這樣的服務是web Service，可是不少並非。此外，不少web Service的應用發生在SOA的環境以外。事實上，不少這樣的應用是B2B，從新回到了web Service最開始的景象(雖然很感激，沒有了green pages)。而且，大部分這樣的B2B web Service僅僅是基於標準的應用編程接口(API)，缺少提供鬆耦合、位置無關和業務敏捷性的架構。此外，有不少的組織機構想嘗試實施SOA，可是僅僅是實施了web Service，形成了和架構毫無關係的冗餘的、不兼容的、經常是沒法管理的服務。

回顧SOA和web Service的歷史，展現了一段很是有趣的迂迴曲折的婚姻，因爲web Service在將SOA引到臺前中發揮了關鍵的做用，即便SOA如今已經超出了web Service能夠提供的範疇。而且，咱們的任務尚未完成，由於圍繞着web Service和SOA還有太多的誤解須要澄清。可能最大的挑戰就是創建一種觀點，SOA是關於業務流程的，而不是集成的。只要廠商還在利用他們的軟件對SOA的成功很是關鍵這樣的錯誤觀念來銷售集成軟件，這種挑戰就存在。