簡單對象協議（SOAP）簡介

2019-11-17 04:51:35

字體：大中小

來源：轉載

供稿：網友

　　"SOAP是在非集中、分布環境中交換信息的輕量級協議。它是基于xml的協議，包括三個部分：封套(envelope)定義了消息內容和處理的框架、一套編碼規則用來表達應用定義數據類型的實例以及表達遠程過程調用和響應的協定。"

　　——SOAP 1.1規范　　第一節 SOAP簡介　　SOAP(Simple Object access PRotocal，簡單對象訪問協議) 技術有助于實現大量異構程序和平臺之間的互操作性，從而使存在的應用能夠被廣泛的用戶所訪問。SOAP是把成熟的基于HTTP的WEB技術與XML的靈活性和可擴展性組合在了一起?！　OAP的一個主要目標是使存在的應用能被更廣泛的用戶所使用。為了實現這個目的，沒有任何SOAP API或SOAP 對象請求代理（SOAP ORB），SOAP是假設你將使用盡可能多的存在的技術。幾個主要的CORBA廠商已經承諾在他們的ORB產品中支持SOAP協議。微軟也承諾在將來的COM版本中支持SOAP。DevelopMentor已經開發了參考實現，它使得在任何平臺上的任何java或Perl程序員都可以使用SOAP。而且IBM和Sun也陸續支持了SOAP協議，和MS合作共同開發SOAP規范和應用。目前SOAP已經成為了W3C和IETF的參考標準之一?！　OAP的指導理念是“它是第一個沒有發明任何新技術的技術”。它采用了已經廣泛使用的兩個協議：HTTP和XML。HTTP用于實現SOAP的RPC風格的傳輸，而XML是它的編碼模式。采用幾行代碼和一個XML解析器，HTTP服務器（如MS的IIS或Apache）馬上成為了SOAP的ORBs。因為目前超過一半的Web服務器采用IIS或Apache, SOAP將會從這兩個產品的廣泛而可靠的使用中獲取利益。這并不意味著所有的SOAP請求必須通過Web服務器來路由，傳統的Web 服務器只是分派SOAP請求的一種方式。因此Web服務如IIS或Apache對建立SOAP性能的應用是充分的，但決不是必要的。　　SOAP把XML的使用代碼化為請求和響應參數編碼模式，并用HTTP作傳輸。這似乎有點抽象。具體地講，一個SOAP方法可以簡單地看作遵循SOAP編碼規則的HTTP請求和響應。一個SOAP終端則可以看作一個基于HTTP的URL，它用來識別方法調用的目標。象CORBA/IIOP一樣，SOAP不需要具體的對象被綁定到一個給定的終端，而是由具體實現程序來決定怎樣把對象終端標識符映射到服務器端的對象。　　SOAP請求是一個HTTP POST請求。SOAP請求的content-type必須用text/xml。而且它必須包含一個請求-URI。服務器怎樣解釋這個請求-URI是與實現相關的，但是許多實現中可能用它來映射到一個類或者一個對象。一個SOAP請求也必須用SOAPMethodName HTTP頭來指明將被調用的方法。簡單地講，SOAPMethodName頭是被URI指定范圍的應用相關的方法名，它是用#符作為分隔符將方法名與URI分割開：SOAPMethodName: urn:strings-com:IString#reverse 　　這個頭表明方法名是reverse，范圍URI是urn:strings-com:Istring。在SOAP中，規定方法名范圍的名域URI在功能上等同于在DCOM 或 IIOP中規定方法名范圍的接口ID。　　簡單的說，一個SOAP請求的HTTP體是一個XML文檔，它包含方法中[in]和[in,out]參數的值。這些值被編碼成為一個顯著的調用元素的子元素，這個調用元素具有SOAPMethodName HTTP頭的方法名和名域URI。調用元素必須出現在標準的SOAP ＜Envelope＞和＜Body＞元素內（后面會更多討論這兩個元素）。下面是一個最簡單的SOAP方法請求：POST /string_server/Object17 HTTP/1.1
Host: 209.110.197.2
Content-Type: text/xml
Content-Length: 152
SOAPMethodName: urn:strings-com:IString#reverse
＜Envelope＞
＜Body＞
＜m:reverse xmlns:m=''urn:strings-com:IString''＞
＜theString＞Hello, World＜/theString＞
＜/m:reverse＞
＜/Body＞
＜/Envelope＞　　SOAPMethodName頭必須與＜Body＞下的第一個子元素相匹配，否則調用將被拒絕。這答應防火墻治理員在不解析XML的情況下有效地過濾對一個具體方法的調用。　　SOAP響應的格式類似于請求格式。響應體包含方法的[out]和 [in,out]參數，這個方法被編碼為一個顯著的響應元素的子元素。這個元素的名字與請求的調用元素的名字相同，但以Response后綴來連接。下面是對前面的SOAP請求的SOAP響應：200 OK Content-Type: text/xml
Content-Length: 162
＜Envelope＞
＜Body＞
＜m:reverseResponse xmlns:m=''urn:strings-com:IString''＞
＜result＞dlroW ,olleH＜/result＞
＜/m:reverseResponse＞
＜/Body＞
＜/Envelope＞
　　這里響應元素被命名為reverseResponse，它是方法名緊跟Response后綴。要注重的是這里是沒有SOAPMethodName HTTP頭的。這個頭只在請求消息中需要，在響應消息中并不需要。更多的請看：http://www.QQread.com/windows/2003/index.Html　　第二節 SOAP體的核心　　SOAP的XML特性是為把數據類型的實例序列化成XML的編碼模式。為了達到這個目的，SOAP不要求使用傳統的RPC風格的代理。而是一個SOAP方法調用包含至少兩個數據類型：請求和響應。考慮這下面個COM IDL代碼：[ uuid(DEADF00D-BEAD-BEAD-BEAD-BAABAABAABAA) ]
interface IBank : IUnknown {
HRESULT withdraw([in] long account,
[out] float *newBalance,
[in, out] float *amount
[out, retval] VARIANT_BOOL *overdrawn);
}　　在任何RPC協議下，account和amount參數的值將出現在請求消息中，newBalance、overdrawn參數的值，還有amount參數的更新值將出現在響應消息中。　　SOAP把方法請求和方法響應提升到了一流狀態。在SOAP中，請求和響應實際上類型的實例。為了理解一個方法比如IBank::withdraw怎樣映射一個SOAP請求和響應類型，考慮下列的數據類型：strUCt withdraw {
long account;
float amount;
};　　這時所有的請求參數被打包成為單一的結構類型。同樣下面的數據表示打包所有響應參數到單一的數據類型。 struct withdrawResponse {
float newBalance;
float amount;
VARIANT_BOOL overdrawn;
};　　再給出下面的簡單的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:http://bofsoap.com/am")
overdrawn = bank.withdraw(3512, amount, newBal)　　這里，在發送請求消息之前，參數被序列化成為一個請求對象。同樣被響應消息接收到的響應對象被反序列化為參數。一個類似的轉變同樣發生在調用的服務器端。　　當通過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，并處理它識別出的頭擴展。這個頭擴展被http://comstuff.com URI識別，并期待一個如下的對象：struct causality {
UUID id;
}; 　　在這種情況下的請求，假如頭元素的URI不能被識別，頭元素可以被安全地忽略。　　但你不能安全的忽略所有的SOAP體中的頭元素。假如一個特定的SOAP頭對正確處理消息是很要害的，這個頭元素能被用SOAP屬性mustUnderstand=’true’標記為必須的。這個屬性告訴接收者頭元素必須被識別并被處理以確保正確的使用。為了強迫前面causality頭成為一個必須的頭，消息將被寫成如下形式：＜soap:Envelope xmlns:soap=''urn:schemas-xmlsoap-org:soap.v1''＞
＜soap:Header＞
＜causality soap:mustUnderstand=''true''xmlns="http://comstuff.com"＞
＜id＞362099cc-aa46-bae2-5110-99aac9823bff＜/id＞
＜/causality＞
＜/soap:Header＞
＜/soap:Envelope＞　　SOAP軟件碰到不能識別必須的頭元素情況時，必須拒絕這個消息并出示一個錯誤。假如服務器在一個SOAP請求中發現一個不能識別的必須的頭元素，它必須返回一個錯誤響應并且不發送任何調用到目標對象。假如客戶端在一個SOAP請求中發現一個不能識別出的必須的頭元素，它必須向調用者返回一個運行時錯誤。在COM情況下，這將映射為一個明顯的HRESULT。更多的請看：http://www.qqread.com/windows/2003/index.html　　第三節 SOAP數據類型　　在SOAP消息中，每個元素可能是一個SOAP結構元素、根元素、存取元素或一個獨立的元素。在SOAP中，soap:Envelope、soap:Body和soap:Header是唯一的組成元素。它們的基本關系由下列XML Schema所描述: ＜schema targetNamespace=''urn:schemas-xmlsoap-org:soap.v1''＞
＜element name=''Envelope''＞
＜type＞
＜element name=''Header'' type=''Header'' minOccurs=''0'' /＞
＜element name=''Body'' type=''Body''minOccurs=''1'' /＞
＜/type＞
＜/element＞
＜/schema＞　　在SOAP元素的四種類型中，除了結構元素外都被用作表達類型的實例或對一個類型實例的引用?！　「厥秋@著的元素，它是soap:Body 或是 soap:Header的直接的子元素。其中soap: Body只有一個根元素，它表達調用、響應或錯誤對象。這個根元素必須是soap:Body的第一個子元素，它的標記名和域名URI必須與HTTP SOAPMethodName頭或在錯誤消息情況下的soap:Fault相對應。而soap:Header元素有多個根元素，與消息相聯系的每個頭擴展對應一個。這些根元素必須是soap:Header的直接子元素，它們的標記名和名域URI表示當前存在擴展數據的類型。　　存取元素被用作表達類型的域、屬性或數據成員。一個給定類型的域在它的SOAP表達將只有一個存取元素。存取元素的標記名對應于類型的域名?？紤]下列Java 類定義：package com.bofsoap.IBank;
public class adjustment {
public int account ;
public float amount ;
}　　在一個SOAP消息中被序列化的實例如下所示：＜t:adjustment xmlns:t=''urn:develop-com:java:com.bofsoap.IBank''＞
＜account＞3514＜/account＞
＜amount＞100.0＜/amount＞
＜/t:adjustment＞　　在這個例子中，存取元素account和amount被稱著簡單存取元素。對引用簡單類型的存取元素，元素值被簡單地編碼為直接在存取元素下的字符數據，如上所示。對引用組合類型的存取元素（就是那些自身用子存取元素來構造的存取元素），有兩個技術來對存取元素進行編碼。最簡單的方法是把被結構化的值直接嵌入在存取元素下?？紤]下面的Java類定義：package com.bofsoap.IBank;
public class transfer {
public adjustment from;
public adjustment to;
}　　假如用嵌入值編碼存取元素，在SOAP中一個序列化的transfer對象如下所示：＜t:transfer xmlns:t=''urn:develop-com:java:com.bofsoap.IBank''＞
＜from＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜/from＞
＜to＞
＜account＞3518＜/account＞
＜amount＞100.0＜/amount＞
＜/to＞
＜/t:transfer＞
　　在這種情況下，adjustment對象的值被直接編碼在它們的存取元素下。在考慮組合存取元素時，需要說明幾個問題。先考慮上面的transfer類。類的from和to的域是對象引用，它可能為空。SOAP用XML Schemas的null屬性來表示空值或引用。下面例子表示一個序列化的transfer對象，它的from域是空的：＜t:transfer xmlns:t=''urn:develop-com:java:com.bofsoap.IBank''
xmlns:xsd=''http://www.w3.org/1999/XMLSchema/instance''＞
＜from xsd:null=''true'' /＞
＜to＞
＜account＞3518＜/account＞
＜amount＞100.0＜/amount＞
＜/to＞
＜/t:transfer＞　　在不存在的情況下， xsd:null屬性的隱含值是false。給定元素的能否為空的屬性是由XML Schema定義來控制的。例如下列XML Schema將只答應from存取元素為空：＜type name=''transfer'' ＞
＜element name=''from'' type=''adjustment'' nullable=''true'' /＞
＜element name=''to'' type=''adjustment'' nullable=''false''/＞
＜/type＞　　在一個元素的Schema聲明中假如沒有nullable屬性，就意味著在一個XML文檔中的元素是不能為空的。Null存取元素的精確格式當前還在修訂中要了解用更多信息參考最新版本的SOAP規范。更多的請看：http://www.qqread.com/windows/2003/index.html
　　與存取元素相關的另一個問題是由于類型關系引起的可代換性。由于前面的adjustment類不是一個final類型的類，transfer對象的from和to域實際引用繼續類型的實例是可能的。為了支持這種類型兼容的替換，SOAP使用一個名域限定的類型屬性的XML Schema約定。這種類型屬性的值是一個對元素具體的類型的限制的名字?？紤]下面的adjustment擴展類：package com.bofsoap.IBank;
public class auditedadjustment extends adjustment {
public int auditlevel;
}　　給出下面Java語言：transfer xfer = new transfer();
xfer.from = new auditedadjustment();
xfer.from.account = 3514;
xfer.from.amount = -100;
xfer.from.auditlevel = 3;
xfer.to = new adjustment();
xfer.to.account = 3518;
xfer.from.amount = 100;　　在SOAP中transfer對象的序列化形式如下所示：＜t:transfer xmlns:xsd=''http://www.w3.org/1999/XMLSchema''
xmlns:t=''urn:develop-com:java:com.bofsoap.IBank''＞
＜from xsd:type=''t:auditedadjustment'' ＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜auditlevel＞3＜/auditlevel ＞
＜/from＞
＜to＞
＜account＞3518＜/account＞
＜amount＞100.0＜/amount＞
＜/to＞
＜/t:transfer＞　　在這里xsd:type屬性引用一個名域限定的類型名，它能被反序列化程序用于實例化對象的正確類型。因為to存取元素引用到一個被預料的類型的實例（而不是一個可代替的繼續類型），xsd:type屬性是不需要的?！　偛诺膖ransfer類設法回避了一個要害問題。假如正被序列化的transfer對象用下面這種方式初始化將會發生什么情況：transfer xfer = new transfer();
xfer.from = new adjustment();
xfer.from.account = 3514; xfer.from.amount = -100;
xfer.to = xfer.from;　　基于以前的議論，在SOAP 中transfer對象的序列化形式如下所示：＜t:transfer xmlns:t=''urn:develop-com:java:com.bofsoap.IBank''＞
＜from＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜/from＞
＜to＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜/to＞
＜/t:transfer＞　　這個表達有兩個問題。首先最輕易理解的問題是同樣的信息被發送了兩次,這導致了一個比實際所需要消息的更大的消息。一個更微妙的但是更重要的問題是由于反序列化程序不能分辨兩個帶有同樣值的adjustment對象與在兩個地方被引用的一個單一的adjustment對象的區別，兩個存取元素間的身份關系就被丟失。假如這個消息接收者已經在結果對象上執行了下面的測試，(xfer.to == xfer.from)將不會返回true。void processTransfer(transfer xfer) {
if (xfer.to == xfer.from)
handleDoubleAdjustment(xfer.to);
else
handleAdjustments(xfer.to, xfer.from);
}　　為了支持必須保持身份關系的類型的序列化，SOAP支持多引用存取元素。目前我們接觸到的存取元素是單引用存取元素，也就是說，元素值是嵌入在存取元素下面的，而且其它存取元素被答應引用那個值（這很類似于在NDR中的[unique]的概念）。多引用存取元素總是被編碼為只包含已知的soap:href屬性的空元素。soap:href屬性總是包含一個代碼片段標識符，它對應于存取元素引用到的實例。假如to和from存取元素已經被編碼為多引用存取元素，序列化的transfer對象如下所示：＜t:transfer xmlns:t=''urn:develop-com:java:com.bofsoap.IBank''＞
＜from soap:href=''#id1'' /＞
＜to soap:href=''#id1'' /＞
＜/t:transfer＞
　　這個編碼假設與adjustment類兼容的一個類型的實例已經在envelope中的其它地方被序列化，而且這個實例已經被用soap:id屬性標記，如下所示：＜t:adjustment soap:id=''id1''xmlns:t=''urn:develop-com:java:com.bofsoap.IBank''＞
＜account＞3514＜/account＞
＜amount＞-100.0＜/amount＞
＜/t:adjustment＞　　第四節結語　　一個遺留的HTTP問題還需要進一步闡明。SOAP支持(但不需要)HTTP擴展框架約定來指定必須的HTTP頭擴展。這些約定主要有兩個目的。首先，它們答應任意的URI被用于限定給定的HTTP頭的范圍(類似XML名域)。第二,這些約定答應把必須的頭與可選的頭區分開來(象soap:mustUnderstand)。下面是一個使用HTTP擴展框架來把SOAPMethodName頭定義成為一個必須的頭擴展：M-POST /Foobar HTTP/1.1
Host: 209.110.197.2
Man: "urn:schemas-xmlsoap-org:soap.v1; ns=42"
42-SOAPMethodName: urn:bobnsid:IFoo#DoIt 　　Man頭映射SOAP URI到前綴為42的頭，并表示沒有認出SOAP的服務器必須返回一個HTTP錯誤，狀態代碼為501 (沒有被實現) 或 510 (沒有被擴展)。HTTP方法必須是M-POST，表明目前是必須的頭擴展。SOAP是一個被類型化的序列化格式，它恰巧用HTTP 作為請求/響應消息傳輸協議。SOAP被設計為與正將出現的XML Schema規范密切配合，并支持在Internet的任何地方運行的COM、CORBA、Perl、Tcl、和Java、C、Python或 php等程序間的互操作性。

上一篇：CMMI評估過程中的需求分析

下一篇：創建股票報價Web服務