基礎知識梳理(1)SOAP

序

最近閑時在想能不能自己搞一套分布式開發的架構出來，因為深感使用标準WCF的一些配置繁瑣，雖然造車輪的工作非常費精力，勞民傷财，但對了解現在的一些如.net remoting, wcf ,webservice的程式設計模型和通信原理是非常有幫助的，可在對SOAP的使用進行分析後決定還是不做了，抛棄代價不說，從資料解析、代碼生成、安全配置等角度，.net平台的分布式其實做的非常好。可SOAP還是要複習一下的，之前寫過一篇文章使用Fiddler來監控WCF的通信過程，觀察SOAP的封裝情況，其實還不夠原生，是以還是重新梳理一下吧。

一項新技術的誕生，往往是因為要解決某些問題，或者改良當時的技術的，SOAP是為了解決應用程式跨網際網路通信問題的，之前的RPC（遠端過程調用）方式雖然也可以解決遠端通信問題，但是安全性和相容性均存在一些問題，我沒有使用過是以不便發表過多言論，這裡隻說SOAP的這個方案帶來的好處：

作為協定，W3C統一程式設計标準

使用HTTP通信，跨網際網路

基于XML，獨立于任何平台

可繞過防火牆

從上面幾點可以看出SOAP的最大好處是：由于有W3C的标準支援，當你部署一個服務到公網，在任何地方，任何平台都能以統一的标準解析服務中的标記，并自己生成通路服務的代碼，進而使用這個服務。

基于這些優點，在2000年微軟，IBM等公司将這套标準形成協定交由著名的W3C，進而才形成了程式設計領域的統一标準，當然，像這些大型的公司據說有部分員工就是W3C的顧問，國内的軟體公司在這方面做的還不夠，标準的制定對技術的發展有很大的推動。

一個服務公開了自己的SOAP服務接口後，服務使用方是怎麼識别出這些内容代表什麼意思呢？這就是标準的意義--形成共識，一個SOAP消息的基本結構是

Envelope  這個節點标注了SOAP的命名空間，也可以說标準，個人了解是這個位址是指出了此檔案的标準制定方

Body節點是說明了這個SOAP的調用方法等

SOAP消息還有另外兩個不太常用的節點

Header可以在這裡加入一些頭資訊（記得嗎？webservice的使用者名密碼驗證）

Fault是指在處理SOAP過程中發生的錯誤資訊

由于SOAP消息是通過HTTP方式發送的，那麼一定是在HTTP标準下進行發送接收的，讓我們通過Fiddler來觀察一下是不是這樣

首先我們向服務端發送一個請求

<a href="http://blog.51cto.com/attachment/201106/202100320.png" target="_blank"></a>

注意上圖中大的矩形中内容其實就是普通的HTTP請求頭，而下面跟着的即是我們的SOAP包了，這個資料包中含有

Post 請求方式

Content-Type 内容類型（這裡是XML）和編碼方式

Host 主機

Content-Lenth 資料大小

當服務端收到這個消息後就會作出相應的處理了，傳回給用戶端了一個資料包

<a href="http://blog.51cto.com/attachment/201106/202127655.png" target="_blank"></a>

服務端傳回的格式依然是标準的HTTP協定格式

HTTP/1.1 200 OK  說明伺服器成功處理請求

Server 是伺服器的IIS，這裡是VS中輕量級的web server

SOAP是應用程式遠端調用的基礎，既然那麼重要，可我們為什麼不常見到上面說的那些消息格式呢？而經常使用的方式可能是：

<a href="http://blog.51cto.com/attachment/201106/202201330.png" target="_blank"></a>

<a href="http://blog.51cto.com/attachment/201106/202220718.png" target="_blank"></a>

<a href="http://blog.51cto.com/attachment/201106/202244915.png" target="_blank"></a>

<a href="http://blog.51cto.com/attachment/201106/202310383.png" target="_blank"></a>

<a href="http://blog.51cto.com/attachment/201106/202333510.png" target="_blank"></a>

      本文轉自xshf12345 51CTO部落格，原文連結：http://blog.51cto.com/wengyuli/593319，如需轉載請自行聯系原作者