7. 在rpc中使用soap
設計soap的目的之一就是利用xml的擴充套件性和靈活性來封裝和交換rpc呼叫。這一 節定義了遠端過程呼叫和應答的統一表示形式。雖然可以預計到這種表示形式最可能被用於與第5節中定義的編碼方式相結合，但也可能有其它的表示形式。 soap的encodingstyle屬性（見4.3.2節）可以用來表明方法呼叫和應答都使用這一節所指定的表示方式。在rpc中使用soap和 soap協議繫結（見第6節）是緊密相關的。在使用http作為繫結協議時，乙個rpc呼叫自然地對映到乙個http請求，rpc應答同樣對映到http 應答。但是，在rpc中使用soap並不限於繫結http協議。
要進行方法呼叫，以下的資訊是必需的：
soap依靠協議繫結提供傳送uri的機制。例如，對http來說，請求的uri指出了呼叫的** 。除了必須是乙個合法的uri之外，soap對乙個位址的格式沒有任何限制。（更多uri的資訊參見 [4]）
7.1 rpc和soap體
rpc方法呼叫和應答都包含在soap body元素中（見4.3節），它們使用如下的表示形式：
方 法錯誤使用soap fault元素（見4.4節）表示。如果繫結的協議有額外的規則表示錯誤，則這些規則也必須要遵從。正如上面所述，方法呼叫和應答結構可以按照第5節中規 則編碼，或者用encodingstyle屬性（見4.1.1節）指定編碼方式。應用程式可以處理缺少引數的請求，但是可能返回乙個錯誤。因為返回結果表 示呼叫成功，錯誤表示呼叫失敗，所以，在方法應答中同時包含返回結果和錯誤是錯誤的。
7.2 rpc和soap頭
在 rpc編碼中，可能會有與方法請求有關但不是正規的方法signature的附加資訊。如果這樣，它必須作為soap頭元素的子元素。使用這種頭元素的一 個例子是在訊息中傳遞事務id。由於事務id不是方法signature的一部分，通常由底層的元件而不是應用程式**控制，所以沒有一種直接的方法在調 用中傳遞這個必要的資訊。通過在頭中新增乙個給定名字的條目，接收方的事務管理器就可以析取這個事務id，而且不影響遠端過程呼叫的**。
8. 安全性考慮
這篇文件中沒有涉及完整性和保密性，這些問題將在以後的版本中描述。
9. 參考文獻
[1] s. bradner, "the internet standards process -- revision 3", rfc2026, harvard university, october 199610。 附錄
a. soap封裝舉例
a.1 請求編碼舉例
例5 類似於例1，但有乙個必要的頭
例6 類似於例1，但有多個請求引數
a.2 應答編碼舉例
例7 與例2類似，但有必要的頭部
例8 與例2類似，但有乙個結構
例9 與例2類似，但處理必要的頭出錯
例10 與例2類似，但處理body出錯
SOAP協議初級指南（二）
目前的技術存在的問題？儘管dcom和iiop都是固定的協議，業界還沒有完全轉向其中任何乙個協議。沒有融合的部分原因是文化的問題所致。而且在當一些組織試圖標準化乙個或另乙個協議的時候，兩個協議的技術適用性就被提出質疑。傳統上認為dcom和corba都是合理伺服器到伺服器端的通訊協議。但是，二者對客戶到...
關於soap協議
前段時間接觸了soap，本來感覺挺難得但是接觸後感覺也就那樣，望新接觸的童鞋們不要和我一樣。要想用soap協議首先我們就需要匯入 乙個關於它的第三方jar包ksoap2，然後後台開發人員會給我們乙個wsdl檔案，這個jar包的鏈結在文章最後會寫上，話不多說，直接上 param methodname ...
SOAP協議簡介
soap 是基於 xml 的簡易協議，可使應用程式在 http 之上進行資訊交換。或者更簡單地說 soap 是用於訪問網路服務的協議。在繼續學習之前，您需要對下面的知識有基本的了解 對於應用程式開發來說，使程式之間進行網際網路通訊是很重要的。目前的應用程式通過使用遠端過程呼叫 rpc 在諸如 dco...