SOAP協議初級指南(五)

2021-08-22 09:39:13 字數 3287 閱讀 1659

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呼叫中的引數。這則正...