xml 作為乙個更好的網路資料表達方式（ndr）
http是乙個相當有用的rpc協議，它提供了iiop或dcom在組幀、連線管理以及序列化物件應用等方面大部分功能的支援。（ 而且urls與iors和objrefs在功能上令人驚嘆的接近）。http所缺少的是用單一的標準格式來表達乙個rpc呼叫中的引數。這則正是xml的用武之地。
象ndr和cdr，xml是乙個與平台無關的中性的資料表達協議。xml允許資料被序列化成乙個可以傳遞的形式，使得它容易地在任何平台上被解碼。xml有以下不同於ndr和cdr的特點：
有大量xml編碼和解碼軟體存在於每個程式設計環境和平台上xml基於文字，相當容易用低技術水平的程式設計環境來處理xml是特別靈活的格式，它容易用一致的方式來被擴充套件為支援可擴充套件性，在xml中每乙個元素和屬性有乙個名域uri與它相聯絡，這個uri用xmlns屬性來指定。
考慮下面的xml文件：
＜reverse_string xmlns="urn:schemas-develop-com:stringprocs"＞
＜string1＞hello, world＜/string1＞
＜comment xmlns=『
『＞ this is a comment!!
＜/comment＞
＜/reverse_string＞
元素＜reverse_string＞和＜string1＞的名域uri是urn:schemas-develop-com:stringprocs。元素＜comment＞的名域uri是
。第二個uri也是乙個url的事實是不重要的。在這兩種情況下，uri簡單地被用來消除元素＜reverse_string＞，＜string1＞，＜comment＞和任何碰巧有同樣標記名的其它元素間的歧義。
為了方便，xml允許名域uris被對映為區域性唯一的字首。這意味著下面的xml文件在語義上等同於上面的文件：
＜sp:reverse_string
xmlns:sp="urn:schemas-develop-com:stringprocs"
xmlns:doc=『
『 ＞＜sp:string1＞hello, world＜/sp:string1＞
＜doc:comment＞
this is a comment!!
＜/doc:comment＞
＜/sp:reverse_string＞
後面的形式對作者來說更容易，尤其是如果有許多名域uris在使用時。
xml也支援帶型別的資料表達。正在推出的xml schema規範為描述xml資料型別標準化了乙個詞匯集。下面是乙個元素＜reverse_string＞的xml schema的描述：
＜schema
xmlns=『
『 targetnamespace=『urn:schemas-develop-com:stringprocs『
＞ ＜element name=『reverse_string『＞
＜type＞
＜element name=『string1『 type=『string『 /＞
＜any minoccurs=『0『 maxoccurs=『*『/＞
＜/type＞
＜/element＞
＜/schema＞
這個xml schema定義闡述了xml名域urn:schemas-develop-com:stringprocs包含了乙個名為＜reverse_string＞的元素，這個元素包含了乙個名為string1的子元素（型別為string），它被0個或更多沒有指定的元素所遵守。
xml schema 規範還定義了一組內建的原始資料型別和建立乙個xml文件中元素的型別的機制。下面的xml文件用xml schema型別屬性來把元素和型別名聯絡在一起：
＜customer
xmlns=『
『 xmlns:xsd=『
『 ＞＜name xsd:type=『string『＞don box＜/name＞
＜age xsd:type=『float『＞23.5＜/name＞
＜/customer＞
連線xml文件事例到xml schema描述的新的乙個機制在本文寫作的時候正在標準化過程中。
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方法請求：
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頭的。這個頭只在請求訊息中需要，在響應訊息中並不需要。
讓許多soap新手困惑的是soap中沒有關於soap伺服器怎樣使用請求頭來分發請求的要求；這被留為乙個實現上的細節。一些soap伺服器將對映請求-uris到類名，並分派呼叫到靜態方法或到在請求持續期內存活的類的例項。其它soap伺服器則將請求-uris對映到始終存活的物件，經常是用查詢字串來編碼乙個用來定位在伺服器程序中的物件關鍵字。還有一些其它的soap伺服器用http cookies來編碼乙個物件關鍵字，這個關鍵字可被用來在每次方法請求中恢復物件的狀態。重要的是客戶對這些區別並不知道。客戶軟體只是簡單遵循http和xml的規則來形成soap請求，讓伺服器自由以它認為最合適的方式來為請求服務。
SOAP協議初級指南（4）
xml 作為乙個更好的網路資料表達方式 ndr http是乙個相當有用的rpc協議，它提供了iiop或dcom在組幀 連線管理以及序列化物件應用等方面大部分功能的支援。而且urls與iors和objrefs在功能上令人驚嘆的接近 http所缺少的是用單一的標準格式來表達乙個rpc呼叫中的引數。這則正...
SOAP協議初級指南（五）
soap體的核心 soap的xml特性是為把資料型別的例項序列化成xml的編碼模式。為了達到這個目的，soap不要求使用傳統的rpc風格的 而是乙個soap方法呼叫包含至少兩個資料型別 請求和響應。考慮這下面個com idl uuid deadf00d bead bead bead baabaaba...
SOAP協議初級指南（2）
目前的技術存在的問題？儘管dcom和iiop都是固定的協議，業界還沒有完全轉向其中任何乙個協議。沒有融合的部分原因是文化的問題所致。而且在當一些組織試圖標準化乙個或另乙個協議的時候，兩個協議的技術適用性就被提出質疑。傳統上認為dcom和corba都是合理伺服器到伺服器端的通訊協議。但是，二者對客戶到...