2001年7月9日，W3C宣布發(fā)布XML協(xié)議工作組（WC）的兩個(gè)工作草案文檔。該工作組發(fā)布了 SOAP規(guī)范版本1.2和XML協(xié)議抽象模型文檔的最新版本。
這次對(duì) SOAP 規(guī)范的更新明確了含義模糊的內(nèi)容，并簡(jiǎn)化了實(shí)現(xiàn)之間的互操作性問題，與此同時(shí)還關(guān)注著現(xiàn)有實(shí)現(xiàn)的向后兼容。雖然工作組為 SOAP 的演化采取了一些積極措施，但工作重點(diǎn)仍集中在澄清問題上。熟悉 SOAP 規(guī)范的 1.1 版本的人應(yīng)該會(huì)對(duì)最新版本一見如故。抽象模型文檔旨在提供一套 SOAP 規(guī)范的讀者們能夠使用的通用術(shù)語(yǔ)和概念。雖然抽象模型文檔并沒有提供實(shí)現(xiàn) SOAP 處理器的設(shè)計(jì)，但是它確實(shí)使大家對(duì)于規(guī)范的制定者們?nèi)绾晤A(yù)見 SOAP 處理器的不同組件之間的協(xié)同工作有了深入的了解。
隨著這些文檔的發(fā)布，現(xiàn)在似乎已是對(duì)工作組最近的一些活動(dòng)、問題以及決定做一個(gè)簡(jiǎn)單概括的時(shí)機(jī)了。然而，這一概述肯定無法做到面面俱到，并且當(dāng)然會(huì)偏向我認(rèn)為值得注意的方面。因此，我在本文的結(jié)尾處提供了更多的詳細(xì)參考資料的鏈接。
發(fā)布會(huì)開始時(shí)，我們?cè)诜▏?guó) Dinard 舉行了一次由Cannon主持的面對(duì)面的（F2F）會(huì)議。（請(qǐng)參閱參考資料，查看 Yves Lafon 拍的這次會(huì)議的照片。）如我們所愿，會(huì)議中所取得的進(jìn)展要比僅僅使用電子郵件地址和電話交流取得的進(jìn)展大得多。其中最明顯的決策之一就是關(guān)于該協(xié)議的名稱。最終的決定是：由于首字母縮寫詞“SOAP”在業(yè)界得到廣泛認(rèn)可，所以我們不想把它的名稱改為其它相對(duì)不知名的詞匯—如XML協(xié)議。一旦決定保留名稱“SOAP”，問題就成了我們是否希望 SOAP 仍舊代表簡(jiǎn)單對(duì)象訪問協(xié)議（Simple Object Access Protocol）。因此我們投票決定，“SOAP”不應(yīng)再作為一個(gè)縮寫詞，而應(yīng)該就是SOAP本身，如今其字母背后也不再有特殊意義。
逐步了解
在 F2F 會(huì)議中所作出的更為重要的決定之一，從實(shí)現(xiàn)者的角度來看，是關(guān)于 SOAP 處理模型的決定。在 SOAP原來的版本中，有一點(diǎn)不甚明確，那就是在進(jìn)行過程中執(zhí)行MustUnderstand（MU）檢查時(shí)，每個(gè)頭部分是否都能以特定的順序得以處理，或者所有這些MU檢查是否必須在處理余下的每個(gè)頭部分之前執(zhí)行。工作組決定，一個(gè) SOAP 處理節(jié)點(diǎn)必須向其它 SOAP 節(jié)點(diǎn)顯示在它處理任何一個(gè)頭部分之前已經(jīng)執(zhí)行了所有的 MU 檢查。因此，如果某一次實(shí)現(xiàn)選擇在 SOAP 消息流入的時(shí)候?qū)ζ溥M(jìn)行處理，并在處理每個(gè)頭部分的同時(shí)進(jìn)行 MU檢查，那么該實(shí)現(xiàn)必須支持一些取消（undo）的概念。所以，如果在處理過程中出現(xiàn)了MU錯(cuò)誤，那么它應(yīng)該沒有先前處理過的頭部分遺留下的副作用。用來說明這個(gè)“無副作用”處理方法的的例子（雖然有些不正常）如清單 1 所示。
清單 1：流式消息的無副作用應(yīng)用
從該示例中可以清楚地看到，如果我們?cè)试S在 SOAP 處理器驗(yàn)證了 fireNuke 頭部分已理解 getAuthorization 頭部分的語(yǔ)義之前就對(duì)它進(jìn)行處理，那么就可能最終得到一些不愿看到的結(jié)果。
工作組以 MustUnderstand 為主題，作了另外一個(gè)關(guān)于返回 MU 出錯(cuò)消息的關(guān)鍵決策。那就是開發(fā)了一種標(biāo)準(zhǔn)的選錯(cuò)機(jī)制（請(qǐng)參閱參考資料），一旦出現(xiàn)未被理解的 MU 頭部分，返回的錯(cuò)誤就將遵循某種格式 — 使得對(duì)于這些錯(cuò)誤的程序性分析容易不少。基本思想是，在 MU 錯(cuò)誤中有一個(gè)定義完好的頭部分，它包含了一份所有未被理解的 MU 頭部分的列表。例如，如果上述示例中的 getAuthorization 頭部分未被理解，那么 MU 錯(cuò)誤中就應(yīng)該出現(xiàn)如清單 2 中所示的頭部分。
清單 2：MU 錯(cuò)誤的可選擇性頭部分
xmlns:f=’http://www.w3.org/2001/06/soap-faults’ >
采取行動(dòng)
最近討論的一些有較大爭(zhēng)議的問題之一就是 SOAPAction HTTP 頭部分的問題。就 SOAPAction HTTP 頭部分當(dāng)前的形式來說，一個(gè)被普遍（但并非一致）認(rèn)同的觀點(diǎn)是它的使用和定義有些模糊。規(guī)范中僅僅說它應(yīng)包含消息的意圖，并且只針對(duì) HTTP 作了定義。對(duì)于在其它傳輸中該做些什么、如何處理在傳輸（HTTP 是其中之一）之間移動(dòng) SOAP 消息的情況，以及“意圖”的含義（它是否用作路由？它是不是目標(biāo)服務(wù)？）則未作規(guī)定。簡(jiǎn)言之，就是一些人想保留它，而另一些人想除去它。我們最終確定了兩個(gè)建議，并將它們提交對(duì)提議持歡迎態(tài)度的 SOAP 社區(qū)：
不鼓勵(lì)使用 SOAPAction。SOAPAction 是 SOAP 的可選部件，它受支持，但并不必要。服務(wù)中“也許”會(huì)需要 SOAPAction，并且任何想要訪問哪些服務(wù)的軟件都“必須”能夠發(fā)送它。
反對(duì)使用 SOAPAction。發(fā)送方“不應(yīng)該”發(fā)送 SOAPAction。接收方“不許”在 SOAPAction 頭部分存在、不存在或它的值的基礎(chǔ)上接受或拒絕接受消息。
在 F2F 會(huì)議中，我們的確對(duì)此進(jìn)行了非正式投票，結(jié)果是 22 票支持，4 票反對(duì) — 未得到一致通過。SOAP 社區(qū)本身非常真實(shí)地反映了工作組的立場(chǎng)（也未一致通過），因此該問題依然存在。
這次對(duì) SOAP 規(guī)范的更新明確了含義模糊的內(nèi)容，并簡(jiǎn)化了實(shí)現(xiàn)之間的互操作性問題，與此同時(shí)還關(guān)注著現(xiàn)有實(shí)現(xiàn)的向后兼容。雖然工作組為 SOAP 的演化采取了一些積極措施，但工作重點(diǎn)仍集中在澄清問題上。熟悉 SOAP 規(guī)范的 1.1 版本的人應(yīng)該會(huì)對(duì)最新版本一見如故。抽象模型文檔旨在提供一套 SOAP 規(guī)范的讀者們能夠使用的通用術(shù)語(yǔ)和概念。雖然抽象模型文檔并沒有提供實(shí)現(xiàn) SOAP 處理器的設(shè)計(jì)，但是它確實(shí)使大家對(duì)于規(guī)范的制定者們?nèi)绾晤A(yù)見 SOAP 處理器的不同組件之間的協(xié)同工作有了深入的了解。
隨著這些文檔的發(fā)布，現(xiàn)在似乎已是對(duì)工作組最近的一些活動(dòng)、問題以及決定做一個(gè)簡(jiǎn)單概括的時(shí)機(jī)了。然而，這一概述肯定無法做到面面俱到，并且當(dāng)然會(huì)偏向我認(rèn)為值得注意的方面。因此，我在本文的結(jié)尾處提供了更多的詳細(xì)參考資料的鏈接。
發(fā)布會(huì)開始時(shí)，我們?cè)诜▏?guó) Dinard 舉行了一次由Cannon主持的面對(duì)面的（F2F）會(huì)議。（請(qǐng)參閱參考資料，查看 Yves Lafon 拍的這次會(huì)議的照片。）如我們所愿，會(huì)議中所取得的進(jìn)展要比僅僅使用電子郵件地址和電話交流取得的進(jìn)展大得多。其中最明顯的決策之一就是關(guān)于該協(xié)議的名稱。最終的決定是：由于首字母縮寫詞“SOAP”在業(yè)界得到廣泛認(rèn)可，所以我們不想把它的名稱改為其它相對(duì)不知名的詞匯—如XML協(xié)議。一旦決定保留名稱“SOAP”，問題就成了我們是否希望 SOAP 仍舊代表簡(jiǎn)單對(duì)象訪問協(xié)議（Simple Object Access Protocol）。因此我們投票決定，“SOAP”不應(yīng)再作為一個(gè)縮寫詞，而應(yīng)該就是SOAP本身，如今其字母背后也不再有特殊意義。
逐步了解
在 F2F 會(huì)議中所作出的更為重要的決定之一，從實(shí)現(xiàn)者的角度來看，是關(guān)于 SOAP 處理模型的決定。在 SOAP原來的版本中，有一點(diǎn)不甚明確，那就是在進(jìn)行過程中執(zhí)行MustUnderstand（MU）檢查時(shí)，每個(gè)頭部分是否都能以特定的順序得以處理，或者所有這些MU檢查是否必須在處理余下的每個(gè)頭部分之前執(zhí)行。工作組決定，一個(gè) SOAP 處理節(jié)點(diǎn)必須向其它 SOAP 節(jié)點(diǎn)顯示在它處理任何一個(gè)頭部分之前已經(jīng)執(zhí)行了所有的 MU 檢查。因此，如果某一次實(shí)現(xiàn)選擇在 SOAP 消息流入的時(shí)候?qū)ζ溥M(jìn)行處理，并在處理每個(gè)頭部分的同時(shí)進(jìn)行 MU檢查，那么該實(shí)現(xiàn)必須支持一些取消（undo）的概念。所以，如果在處理過程中出現(xiàn)了MU錯(cuò)誤，那么它應(yīng)該沒有先前處理過的頭部分遺留下的副作用。用來說明這個(gè)“無副作用”處理方法的的例子（雖然有些不正常）如清單 1 所示。
清單 1：流式消息的無副作用應(yīng)用
從該示例中可以清楚地看到，如果我們?cè)试S在 SOAP 處理器驗(yàn)證了 fireNuke 頭部分已理解 getAuthorization 頭部分的語(yǔ)義之前就對(duì)它進(jìn)行處理，那么就可能最終得到一些不愿看到的結(jié)果。
工作組以 MustUnderstand 為主題，作了另外一個(gè)關(guān)于返回 MU 出錯(cuò)消息的關(guān)鍵決策。那就是開發(fā)了一種標(biāo)準(zhǔn)的選錯(cuò)機(jī)制（請(qǐng)參閱參考資料），一旦出現(xiàn)未被理解的 MU 頭部分，返回的錯(cuò)誤就將遵循某種格式 — 使得對(duì)于這些錯(cuò)誤的程序性分析容易不少。基本思想是，在 MU 錯(cuò)誤中有一個(gè)定義完好的頭部分，它包含了一份所有未被理解的 MU 頭部分的列表。例如，如果上述示例中的 getAuthorization 頭部分未被理解，那么 MU 錯(cuò)誤中就應(yīng)該出現(xiàn)如清單 2 中所示的頭部分。
清單 2：MU 錯(cuò)誤的可選擇性頭部分
采取行動(dòng)
最近討論的一些有較大爭(zhēng)議的問題之一就是 SOAPAction HTTP 頭部分的問題。就 SOAPAction HTTP 頭部分當(dāng)前的形式來說，一個(gè)被普遍（但并非一致）認(rèn)同的觀點(diǎn)是它的使用和定義有些模糊。規(guī)范中僅僅說它應(yīng)包含消息的意圖，并且只針對(duì) HTTP 作了定義。對(duì)于在其它傳輸中該做些什么、如何處理在傳輸（HTTP 是其中之一）之間移動(dòng) SOAP 消息的情況，以及“意圖”的含義（它是否用作路由？它是不是目標(biāo)服務(wù)？）則未作規(guī)定。簡(jiǎn)言之，就是一些人想保留它，而另一些人想除去它。我們最終確定了兩個(gè)建議，并將它們提交對(duì)提議持歡迎態(tài)度的 SOAP 社區(qū)：
不鼓勵(lì)使用 SOAPAction。SOAPAction 是 SOAP 的可選部件，它受支持，但并不必要。服務(wù)中“也許”會(huì)需要 SOAPAction，并且任何想要訪問哪些服務(wù)的軟件都“必須”能夠發(fā)送它。
反對(duì)使用 SOAPAction。發(fā)送方“不應(yīng)該”發(fā)送 SOAPAction。接收方“不許”在 SOAPAction 頭部分存在、不存在或它的值的基礎(chǔ)上接受或拒絕接受消息。
在 F2F 會(huì)議中，我們的確對(duì)此進(jìn)行了非正式投票，結(jié)果是 22 票支持，4 票反對(duì) — 未得到一致通過。SOAP 社區(qū)本身非常真實(shí)地反映了工作組的立場(chǎng)（也未一致通過），因此該問題依然存在。