soap體的核心
soap的xml特性是為把資料型別的例項序列化成xml的編碼模式。為了達到這個目的，soap不要求使用傳統的rpc風格的**。而是乙個soap方法呼叫包含至少兩個資料型別：請求和響應。考慮這下面個com idl**：
[ uuid(deadf00d-bead-bead-bead-baabaabaabaa) ]
inte***ce ibank : iunknown
在任何rpc協議下，account和amount引數的值將出現在請求訊息中，newbalance，overdrawn引數的值，還有amount引數的更新值將出現在響應訊息中。
soap把方法請求和方法響應提公升到了一流狀態。在soap中，請求和響應實際上型別的例項。為了理解乙個方法比如ibank::withdraw怎樣對映乙個soap請求和響應型別，考慮下列的資料型別：
struct withdraw ;
這是乙個所有的請求引數被打包成為乙個單一的資料型別。同樣下面的資料表示打包所有響應引數到乙個單一的資料型別。
struct withdrawresponse ;
再給出下面的簡單的visual basic程式，它使用了以前定義的ibank介面：
dim bank as ibank
dim amount as single
dim newbal as single
dim overdrawn as boolean
amount = 100
set bank = getobject("soap:")
overdrawn = bank.withdraw(3512, amount, newbal)
你能夠想象底層的**（可能是乙個soap，dcom，或iiop**）看上去象圖8中所表示的那樣。這裡，在傳送請求訊息之前，引數被序列化成為乙個請求物件。同樣被響應訊息接收到的響應物件被反序列化為引數。乙個類似的轉變同樣發生在呼叫的伺服器端。
當通過soap呼叫方法時，請求物件和響應物件被序列化成一種已知的格式。每個soap體是乙個xml文件，它具有乙個顯著的稱為＜envelope＞的根元素。標記名＜envelope＞由soap uri (urn:schemas-xmlsoap-org:soap.v1)來劃定範圍，所有soap專用的元素和屬性都是由這個uri來劃定範圍的。soap envelope包含乙個可選的＜header＞元素，緊跟乙個必須的＜body＞元素。＜body＞元素也有乙個顯著的根元素，它或者是乙個請求物件或者是乙個響應物件。下面是乙個ibank::withdraw請求的編碼：
＜soap:envelope
xmlns:soap=『urn:schemas-xmlsoap-org:soap.v1『＞
＜soap:body＞
＜ibank:withdraw xmlns:ibank=
『urn:uuid:deadf00d-bead-bead-bead-baabaabaabaa『＞
＜account＞3512＜/account＞
＜amount＞100＜/amount＞
＜/ibank:withdraw＞
＜/soap:body＞
＜/soap:envelope＞
下列響應訊息被編碼為：
＜soap:envelope
xmlns:soap=『urn:schemas-xmlsoap-org:soap.v1『＞
＜soap:body＞
＜ibank:withdrawresponse xmlns:ibank=
『urn:uuid:deadf00d-bead-bead-bead-baabaabaabaa『＞
＜newbalance＞0＜/newbalance＞
＜amount＞5＜/amount＞
＜overdrawn＞true＜/overdrawn＞
＜/ibank:withdrawresponse＞
＜/soap:body＞
＜/soap:envelope＞
注意[in, out]引數出現在兩個訊息中。
在檢查了請求和響應物件的格式後，你可能已經注意到序列化格式通常是：
＜t:typename xmlns:t=『namespaceuri『＞ ;
＜fieldname1＞field1value＜/fieldname1＞
＜fieldname2＞field2value＜/fieldname2＞
＜/t:typename＞
在請求的情況下，型別是隱式的c風格的結構，它由對應方法中的[in]和[in, out]引數組成。對響應來說，型別也是隱式的c風格的結構，它由對應方法中的[out]和[in, out]引數組成。這種每個域對應乙個子元素的風格有時被稱為元素正規格式(enf)。一般情況下，soap只用xml特性來傳達描述包含在元素內容中資訊的注釋。
象dcom和iiop一樣，soap支援協議頭擴充套件。soap用可選的＜header＞元素來傳載被協議擴充套件所使用的資訊。如果客戶端的soap軟體包含要傳送頭資訊，原始的請求將可能如圖9所示。在這種情況下命名causality的頭將與請求一起序列化。收到請求後，伺服器端軟體能檢視頭的名域uri，並處理它識別出的頭擴充套件。這個頭擴充套件被 uri識別，並期待乙個如下的物件：
struct causality ;
在這種情況下的請求，如果頭元素的uri不能被識別，頭元素可以被安全地忽略。
但你不能安全的忽略所有的soap體中的頭元素。如果乙個特定的soap頭對正確處理訊息是很關鍵的，這個頭元素能被用soap屬性mustunderstand=』true』標記為必須的。這個屬性告訴接收者頭元素必須被識別並被處理以確保正確的使用。為了強迫前面causality頭成為乙個必須的頭，訊息將被寫成如下形式：
＜soap:envelope
xmlns:soap=『urn:schemas-xmlsoap-org:soap.v1『＞
＜soap:header＞
＜causality
soap:mustunderstand=『true『
xmlns=""＞
＜id＞362099cc-aa46-bae2-5110-99aac9823bff＜/id＞
＜/causality＞
＜/soap:header＞
＜!— soap:body element elided for clarity —＞
＜/soap:envelope＞
soap軟體遇到不能識別必須的頭元素情況時，必須拒絕這個訊息並出示乙個錯誤。如果伺服器在乙個soap請求中發現乙個不能識別的必須的頭元素，它必須返回乙個錯誤響應並且不傳送任何呼叫到目標物件。如果客戶端在乙個soap請求中發現乙個不能識別出的必須的頭元素，它必須向呼叫者返回乙個執行時錯誤。（在com情況下，這將對映為乙個明顯的hresult）
SOAP協議初級指南（五）
soap體的核心 soap的xml特性是為把資料型別的例項序列化成xml的編碼模式。為了達到這個目的，soap不要求使用傳統的rpc風格的 而是乙個soap方法呼叫包含至少兩個資料型別 請求和響應。考慮這下面個com idl uuid deadf00d bead bead bead baabaaba...
SOAP協議初級指南（2）
目前的技術存在的問題？儘管dcom和iiop都是固定的協議，業界還沒有完全轉向其中任何乙個協議。沒有融合的部分原因是文化的問題所致。而且在當一些組織試圖標準化乙個或另乙個協議的時候，兩個協議的技術適用性就被提出質疑。傳統上認為dcom和corba都是合理伺服器到伺服器端的通訊協議。但是，二者對客戶到...
SOAP協議初級指南（4）
xml 作為乙個更好的網路資料表達方式 ndr http是乙個相當有用的rpc協議，它提供了iiop或dcom在組幀 連線管理以及序列化物件應用等方面大部分功能的支援。而且urls與iors和objrefs在功能上令人驚嘆的接近 http所缺少的是用單一的標準格式來表達乙個rpc呼叫中的引數。這則正...