Web服務(wù)內(nèi)幕，第8部分：關(guān)于Soap的決策

申請免費(fèi)試用、咨詢電話：400-8352-114

Web服務(wù)內(nèi)幕，第8部分：關(guān)于Soap的決策

－－SOAP 1.2 的制定

Doug Davis（dug@us.ibm.com）

顧問程序員，IBM

2001 年 8 月

萬維網(wǎng)聯(lián)盟（The World Wide Web Consortium，W3C）已經(jīng)發(fā)布了 SOAP 規(guī)范及 XML 抽象模型的更新草案。請跟隨 Doug Davis 深入了解導(dǎo)致這些新版本發(fā)行的近期會議的最新情況。

介紹

2001 年 7 月 9 日，W3C 宣布發(fā)布 XML 協(xié)議工作組（WC）的兩個工作草案文檔。該工作組發(fā)布了 SOAP 規(guī)范版本 1.2 和 XML 協(xié)議抽象模型文檔的最新版本。

這次對 SOAP 規(guī)范的更新明確了含義模糊的內(nèi)容，并簡化了實(shí)現(xiàn)之間的互操作性問題，與此同時(shí)還關(guān)注著現(xiàn)有實(shí)現(xiàn)的向后兼容。雖然工作組為 SOAP 的演化采取了一些積極措施，但工作重點(diǎn)仍集中在澄清問題上。熟悉 SOAP 規(guī)范的 1.1 版本的人應(yīng)該會對最新版本一見如故。抽象模型文檔旨在提供一套 SOAP 規(guī)范的讀者們能夠使用的通用術(shù)語和概念。雖然抽象模型文檔并沒有提供實(shí)現(xiàn) SOAP 處理器的設(shè)計(jì)，但是它確實(shí)使大家對于規(guī)范的制定者們?nèi)绾晤A(yù)見 SOAP 處理器的不同組件之間的協(xié)同工作有了深入的了解。

隨著這些文檔的發(fā)布，現(xiàn)在似乎已是對工作組最近的一些活動、問題以及決定做一個簡單概括的最佳時(shí)機(jī)了。然而，這一概述肯定無法做到面面俱到，并且當(dāng)然會偏向我認(rèn)為值得注意的方面。因此，我在本文的結(jié)尾處提供了更多的詳細(xì)參考資料的鏈接。

發(fā)布會開始時(shí)，我們在法國 Dinard 舉行了一次由 Cannon 主持的面對面的（F2F）會議。（請參閱參考資料，查看 Yves Lafon 拍的這次會議的照片。）如我們所愿，會議中所取得的進(jìn)展要比僅僅使用電子郵件地址和電話交流取得的進(jìn)展大得多。其中最明顯的決策之一就是關(guān)于該協(xié)議的名稱。最終的決定是：由于首字母縮寫詞“SOAP”在業(yè)界得到廣泛認(rèn)可，所以我們不想把它的名稱改為其它相對不知名的詞匯 — 如 XML 協(xié)議。一旦決定保留名稱“SOAP”，問題就成了我們是否希望 SOAP 仍舊代表簡單對象訪問協(xié)議（Simple Object Access Protocol）。因此我們投票決定，“SOAP”不應(yīng)再作為一個縮寫詞，而應(yīng)該就是 SOAP 本身，如今其字母背后也不再有特殊意義。

逐步了解

在 F2F 會議中所作出的更為重要的決定之一，從實(shí)現(xiàn)者的角度來看，是關(guān)于 SOAP 處理模型的決定。在 SOAP 原來的版本中，有一點(diǎn)不甚明確，那就是在進(jìn)行過程中執(zhí)行 MustUnderstand（MU）檢查時(shí)，每個頭部分是否都能以特定的順序得以處理，或者所有這些 MU 檢查是否必須在處理余下的每個頭部分之前執(zhí)行。工作組決定，一個 SOAP 處理節(jié)點(diǎn)必須向其它 SOAP 節(jié)點(diǎn)顯示在它處理任何一個頭部分之前已經(jīng)執(zhí)行了所有的 MU 檢查。因此，如果某一次實(shí)現(xiàn)選擇在 SOAP 消息流入的時(shí)候?qū)ζ溥M(jìn)行處理，并在處理每個頭部分的同時(shí)進(jìn)行 MU 檢查，那么該實(shí)現(xiàn)必須支持一些取消（undo）的概念。所以，如果在處理過程中出現(xiàn)了 MU 錯誤，那么它應(yīng)該沒有先前處理過的頭部分遺留下的副作用。用來說明這個“無副作用”處理方法的最好的例子（雖然有些不正常）如清單 1 所示。

清單 1：流式消息的無副作用應(yīng)用

從該示例中可以清楚地看到，如果我們允許在 SOAP 處理器驗(yàn)證了 fireNuke 頭部分已理解 getAuthorization 頭部分的語義之前就對它進(jìn)行處理，那么就可能最終得到一些不愿看到的結(jié)果。

工作組以 MustUnderstand 為主題，作了另外一個關(guān)于返回 MU 出錯消息的關(guān)鍵決策。那就是開發(fā)了一種標(biāo)準(zhǔn)的選錯機(jī)制（請參閱參考資料），一旦出現(xiàn)未被理解的 MU 頭部分，返回的錯誤就將遵循某種格式 — 使得對于這些錯誤的程序性分析容易不少。基本思想是，在 MU 錯誤中有一個定義完好的頭部分，它包含了一份所有未被理解的 MU 頭部分的列表。例如，如果上述示例中的 getAuthorization 頭部分未被理解，那么 MU 錯誤中就應(yīng)該出現(xiàn)如清單 2 中所示的頭部分。

清單 2：MU 錯誤的可選擇性頭部分

xmlns:f= 'http://www.w3.org/2001/06/soap-faults'>

采取行動

最近討論的一些有較大爭議的問題之一就是 SOAPAction HTTP 頭部分的問題。就 SOAPAction HTTP 頭部分當(dāng)前的形式來說，一個被普遍（但并非一致）認(rèn)同的觀點(diǎn)是它的使用和定義有些模糊。規(guī)范中僅僅說它應(yīng)包含消息的意圖，并且只針對 HTTP 作了定義。對于在其它傳輸中該做些什么、如何處理在傳輸（HTTP 是其中之一）之間移動 SOAP 消息的情況，以及“意圖”的含義（它是否用作路由？它是不是目標(biāo)服務(wù)？）則未作規(guī)定。簡言之，就是一些人想保留它，而另一些人想除去它。我們最終確定了兩個建議，并將它們提交對提議持歡迎態(tài)度的 SOAP 社區(qū)：

不鼓勵使用 SOAPAction。SOAPAction 是 SOAP 的可選部件，它受支持，但并不必要。服務(wù)中“也許”會需要 SOAPAction，并且任何想要訪問哪些服務(wù)的軟件都“必須”能夠發(fā)送它。

反對使用 SOAPAction。發(fā)送方“不應(yīng)該”發(fā)送 SOAPAction。接收方“不許”在 SOAPAction 頭部分存在、不存在或它的值的基礎(chǔ)上接受或拒絕接受消息。

在 F2F 會議中，我們的確對此進(jìn)行了非正式投票，結(jié)果是 22 票支持，4 票反對 — 未得到一致通過。SOAP 社區(qū)本身非常真實(shí)地反映了工作組的立場（也未一致通過），因此該問題依然存在。

名稱空間中的內(nèi)容

有一點(diǎn)是意料之中的，即新的 SOAP 版本還將有新的名稱空間。目前，新的名稱空間為 http://www.w3.org/2001/06/soap-envelope。

多少由于新的名稱空間的關(guān)系，同時(shí)還開發(fā)了一個新版本的錯誤模型?；舅枷胧牵?dāng)一個 SOAP 處理節(jié)點(diǎn)接收到帶有它不支持的名稱空間的 SOAP 消息時(shí)，它必須返回一個帶有舊的 SOAP 1.1 名稱空間（http://schemas.xmlsoap.org/soap/envelope）的 VersionMismatch 錯誤，并且應(yīng)該包括一個包含受支持的 SOAP 名稱空間列表的 Upgrade 頭部分。例如，如果一個 SOAP 1.2 處理節(jié)點(diǎn)接收到一個 SOAP 1.1 消息卻無法處理，因?yàn)樗恢С?SOAP 1.1 語義，那么它就應(yīng)該返回如清單 3 所示的出錯消息。

清單 3：SOAP 1.2 與 1.1 請求不匹配的出錯消息


xmlns:ns1="http://www.w3.org/2001/06/soap-envelope"/>




env:VersionMismatch
Version Mismatch

使用 XML infoset

近來，關(guān)于 infoset 的課題被提了出來。Infoset 是這樣一個機(jī)制，通過它，不必使用空白、尖括號以及單、雙引號等瑣碎的細(xì)節(jié)符號就能描述 XML 文檔。它允許對包含在 XML 中的實(shí)際數(shù)據(jù)而不是 XML 的特定格式進(jìn)行更為抽象的討論。這一機(jī)制的一種令人感興趣的用途，就是它使新的 XML 格式（比如擁有更簡潔的句法的二進(jìn)制 XML）的出現(xiàn)成為了可能。在調(diào)查 Infoset 及其在 SOAP 規(guī)范中可能的用途的過程中，Martin Gudgin 根據(jù) XML infoset 重寫了規(guī)范的第 4 部分。因此，從 Martin 所完成的工作中抽取一個片斷來看，一個 Infoset 定義的頭部分元素示例可能包含以下內(nèi)容：

頭部分的本地名稱

“http://www.w3.org/2001/06/soap-envelope/”的名稱空間名稱

零或更多個符合名稱空間條件的屬性信息項(xiàng)目（Attribute Information Items）

零或更多個符合名稱空間條件的元素信息子項(xiàng)目（Element Information Item children）。

請注意，它是如何將重點(diǎn)集中在包含在 XML 中的實(shí)際數(shù)據(jù)上，而非數(shù)據(jù)的特定文本格式上的。在更高層次上，比如，在關(guān)于如何定義一種特定傳輸上的 SOAP 的定義中，其注意力就在于 XML 的實(shí)際物質(zhì)表現(xiàn)的特定細(xì)節(jié)發(fā)生之處。

同樣值得注意的還有讓數(shù)據(jù)類型 boolean 接受 0、1、ture 和 false（“0”為 MU 頭部分中的缺省值）的決定。

繼續(xù)下一項(xiàng)任務(wù)

XML 協(xié)議組現(xiàn)在有兩個新的下屬機(jī)構(gòu)：傳輸綁定任務(wù)組（Transport Binding Task Force）和 RPC 任務(wù)組（RPC Task Force）。這兩個任務(wù)組的目標(biāo)主要是決定涉及各個課題的 SOAP 規(guī)范的語法和語義。傳輸綁定任務(wù)組關(guān)于最基本的問題（諸如“什么是綁定？”這樣基本的問題）已經(jīng)有了不少討論。如果您對其中的任何課題感興趣的話，我建議您瀏覽一遍郵件列表文檔，并查看一下該工作小組的 Web 頁。讓我來對如此廣泛多樣的選項(xiàng)作總結(jié)可能反而會對原意造成不可思議的損害。那么我們暫且假設(shè)它涉及的不同觀點(diǎn)相當(dāng)多。RPC 任務(wù)組剛剛成立，現(xiàn)仍處于收集問題的階段。

還有些什么？除了本文中提到的問題以外，XML 工作組的面前還擺著不少尚待解決的問題。想獲得詳盡的列表，請參閱問題列表。一些更為活躍的問題（如 SOAPAction）肯定會讓您興奮的。對于任何對 SOAP 感興趣的人，無論是技術(shù)的熱衷者還是實(shí)現(xiàn)者，我都建議您通過訂閱并加入 xml-dist-app 郵件列表來留意工作組的發(fā)展。該工作組在一個方面是非常獨(dú)特的，那就是：它大概是 W3C 工作組中最開放的一個了 — 我們的所有工作幾乎都是以一種開放、公共的方式完成的，并且 SOAP 社區(qū)的參與、意見和反饋都是其工作得以成功的關(guān)鍵因素。

作者的免責(zé)聲明：對于本文中提及的任何、或所有決策，都應(yīng)視為工作組在當(dāng)前時(shí)刻想法的快照。有相當(dāng)多的人急切希望工作組完成其工作，因此可能會根據(jù)工作組的臨時(shí)決策做出實(shí)現(xiàn)的選擇，這是可以理解的，但請注意，工作組如今所作出的決策可能會在日后有所改變。

W3C XML 協(xié)議工作組

W3C XML 協(xié)議工作組成立于 2000 年 9 月 13 日，它的主要工作是為 XML 開發(fā)傳輸協(xié)議。雖然工作組關(guān)注最多的是 SOAP，但它們同時(shí)也考慮其它相關(guān)的協(xié)議，如 XML-RPC、WDDX 等等。他們與其它基于 XML 的標(biāo)準(zhǔn)開發(fā)團(tuán)體（如 IETF、RosettaNet 和 ebXML）也有聯(lián)系，特別是在關(guān)于用 XML 編碼的傳輸機(jī)制領(lǐng)域。

它有著代表 40 多個組織機(jī)構(gòu)的 70 余名成員，這些組織機(jī)構(gòu)包括小型和大型的軟件廠商，如 IBM、Oracle、Allaire/Macromedia、Microsoft、Sun、Software AG、webMethods、Idoox、Akamai 等等，以及基于研究工作的組織機(jī)構(gòu)，如 MITRE Corp.、Philips Research、DaimlerChrysler Research 和美國國會圖書館。

工作組分為抽象模型小組（Abstract Model Group）、傳輸綁定任務(wù)組（Transport Binding Task Force）以及 RPC 任務(wù)組（RPC Task Force）。

他們?nèi)杂幸婚L串問題有待解決。如果您想直接向工作組提出任何技術(shù)性問題，請使用他們的郵件列表。

參考資料