在很多場合的交流中，常常遇到把
SOA和Web Service混用的情況，所以想在這次的Blog里，結合網上的各種觀
點，談談個人對兩個概念的理解。用一句話來概括基本的觀點就是“SOA不是Web Service，Web Service是目前最適合實現SOA的技術”。 之所以SOA和Web Service被混為一談，最可能的原因了也就在于此吧。
早在1996年Gartner就前瞻性地提出了面向服務架構的思想(SOA)，該年赫赫有名的Netscape
才發布了Navigator 2.0，整個互聯網剛剛慶祝超過500,000網站的誕生，網絡上的商業應用還是鳳毛麟角，Web
Service不知為何物，SOA還只是束之高閣的理論概念。直到2000年以后，W3C才成立了相關的委員會，開始討論Web
Service的相關標準;各大廠商一邊積極參與標準制定，一邊推出了一系列實實在在的產品。新的技術和新的產品出現，SOA找到了可以依托的憑借。隨著
Web Service技術的推出和應用，SOA的思想被一個個效益顯著的信息系統建設項目不斷的示范，才逐漸成為現今的熱門話題。類似的情況讓人聯想到愛因斯坦提出來的理論，著名的質量能量轉化等式E=mc2，直到人們掌握了核子裂變技術，才成功生產出了原子彈，向世人展示了這個理論等式的巨大威力。
因為現在幾乎所有的SOA應用場合都是和Web Service綁定的，所以不免有時候這兩個概念混用。不可否認Web
Service是現在最適合實現SOA的技術，SOA的走紅在很大程度上歸功于Web
Service標準的成熟和應用普及。因為現在大家基本上認同Web Service技術在幾方面體現了SOA的需要：
首先是基于標準訪問的獨立功能實體滿足了松耦合要求：在Web Service中所有的訪問都通過SOAP訪問進行，用WSDL定義的接口封裝，通過UDDI進行目錄查找，可以動態改變一個服務的提供方而無需影響客戶端的配置，外界客戶端是根本不關心訪問服務器端的實現。
其次，適合大數據量低頻率訪問符合服務大顆粒度功能：基于性能和效率平衡的要求，SOA的服務提供的是大顆粒度的應用功能，而且跨系統邊界的訪問頻率也不會象程序間函數調用那么頻繁。通過使用WSDL和基于文本(Literal)的SOAP請求，可以實現能一次性接收處理大量數據。
最后，基于標準的文本消息傳遞為異構系統提供通訊機制：Web Service所有的通訊是通過SOAP進行的，而SOAP是基于XML的，XML是結構化的文本消息。從最早的EDI開始，文本消息也許是異構系統間通訊最好的消息格式，適用于SOA強調的服務對異構后天宿主系統的透明性。
綜合上述觀點，Web Service不愧為當前SOA的最好選擇。然而，就SOA思想本身而言，并不一定要局限于Web
Service方式的實現。更應該看到的是SOA本身強調的是實現業務邏輯的敏捷性要求，是從業務應用角度對信息系統實現和應用的抽象。隨著人們認識的提
高，還會有新技術不斷的發明出來，更好的來滿足這個要求。就好像在核子裂變之后，人們又發現了威力更加強大的核子聚變。為了要有一個更高的角度來看待問
題，SOA和Web Service還是不應該混為一談
Web Service是就現在而言最適合實現SOA的一些技術的集合，事實上最近SOA的火爆在很大程度上歸功于Web
Service標準的成熟和應用的普及為廣泛的實現SOA架構提供了基礎。下面讓我們看看Web
Service中的各種協議是如何互相工作來滿足SOA所需的特點的：
獨立的功能實體：通過UDDI的目錄查找，我們可以動態改變一個服務的提供方而無需影響客戶端的應用程序配置。所有的訪問都通過SOAP訪問進行，只要WSDL接口封裝良好，外界客戶端是根本沒有辦法直接訪問服務器端的數據的。
大數據量低頻率訪問：通過使用WSDL和基于文本(Literal)的SOAP請求，我們可以實現能一次性接收大量數據的接口。這里需要著重指出的是
SOAP請求分文本方式和遠程調用(RPC)兩種方式，正如上文已經提到的，采用遠程調用方式的SOAP請求并不符合這點要求。但是令人遺憾的是現有的大
多數SOAP請求采用的仍然是遠程調用(RPC)方式，在某些平臺上，例如IBM
WebSphere的早期版本，甚至沒有提供文本方式的SOAP支持。
基于文本的消息傳遞：Web Service所有的通訊是通過SOAP進行的，而SOAP是基于XML的，不同版本之間可以使用不同的DTD或者XML Schema加以辨別和區分。因此只需要我們為不同的版本提供不同的處理就可以輕松實現版本控制的目標。
screen.width-500)this.width=screen.width-500" border="0">