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