本文是一個由四篇文章組成的系列的第三篇（請參閱 參考資料），本系列文章旨在介紹創建、描述和發布 Web 服務的過程。在第一部分中，我借助 WSDL 編制示例講解了如何描述一個 Web 服務。在第二部分中，我討論了 SOAP 的體系結構及其語義。在本文中，我將看一看與 SOAP 相關的互操作性問題。

Web 服務模型將整個 B2B 領域分成三個步驟或三個域：描述一個服務、將該服務與具體的實現綁定，然后通過注冊中心發布該服務。這三個步驟彼此獨立，會引發各自的互操作性問題。

WSDL（Web 服務描述語言（Web Services Description Language））構成描述域，SOAP 覆蓋綁定域，統一描述、發現和集成（Universal Description, Discovery and Integration，UDDI）注冊中心覆蓋發布域。我在這部分的討論將僅限于與綁定域相關的互操作性問題。我將從討論 SOAP 的發展入手，接著討論實際的 SOAP 互操作性問題。

SOAP 版本的發展

1999 年，當 XML Schema 規范仍在發展中且被視為 SOAP 規范的關鍵部分的時候，W3C 就開始了關于 SOAP 規范的工作。SOAP 使用 XML Schema 數據類型定義來定義并實例化 SOAP 中的數據類型。

2000 年 5 月，SOAP 1.1 作為 W3C 紀要發行（ 參考資料）。這是來自 Microsoft、IBM、Lotus Development 和 UserLand Software, Inc. 的開發人員共同努力的成果。SOAP 1.1 采用帶有 1999 名稱空間 URI（ "http://www.w3.org/1999/XMLSchema"）的 XML Schema 工作草案。目前，SOAP 1.2（ 參考資料）已經很接近于成為候選推薦，而且它已經采用了 XML Schema 推薦（2001 年 5 月）和 XML Schema 的 2001 名稱空間 URI（ "http://www.w3.org/2001/XMLSchema"）。


互操作性問題

我將從基于傳輸（HTTP）的 SOAP 互操作性問題入手。

1. 傳輸

SOAP 1.1 規范允許在 HTTP 請求中發送 SOAP 消息。如同第 2 部分（ 參考資料）中所描述的，SOAP 與 HTTP 集成并不會影響 SOAP 的語義。SOAP 規范將必選的 SOAPAction 頭添加到 HTTP 請求頭中。我在前一篇文章中已經描述過， SOAPAction 頭的合法取值有三種：


它可以為空
它可以是一個用引號括起來的空字符串
它還可以是一個任意的 URI

這種靈活性使 SOAP 實現能夠選擇它們自己的 SOAPAction 樣式及其功能。但是這種靈活性已經引發了互操作性問題。

為了研究這些互操作性問題，我創建了一個 SOAP 客戶機（ 參考資料），該客戶機向 SOAP 服務器（由 URL 參數指定的）發送一個請求并且在接收到時顯示服務器響應。我在更改 SOAPAction 頭的值之后將簡單的 SOAP 請求發送給不同的服務器，從而查看服務器如何支持 SOAP 1.1 規范所允許的三種頭。

除 SOAPAction 頭（這個頭由我操作）外，我的測試均按照 SOAPBuilders 的第 2 輪（基本）echoString 測試（SOAPBuilders' Round 2 (Base) echoString test）（ 參考資料）進行。您應該訪問 SOAPBuilders 的第 2 輪測試站點以獲得 WSDL 文件（基本測試），該文件描述了我在執行測試期間將調用的測試 Web 服務。

被測試的 SOAP 服務器

我在本文中測試了下列 SOAP 服務器：

Apache Axis SOAP Server
Apache SOAP 2.2 Server
WhiteMesa 2.7 SOAP Server
IONA XMLBus
SOAP::Lite
EasySOAP++
4S4C
Microsoft ASP.NET Web Services



我在測試中使用了四個 SOAP 請求。

清單 1 包含了 SOAPAction 頭的值用雙引號括起來的 SOAP 請求。 SOAPAction 頭的值與 WSDL 文件中給定的值（ "http://soapinterop.org/"）一樣。
清單 2 包含了相同的 SOAPAction 頭值，但是沒有雙引號（ http://soapinterop.org/）。
清單 3 包含了一個與 WSDL 文件中給定的頭不同的 SOAPAction 頭（ "http://differentfromwsdl.org/"）。
清單 4 為 SOAPAction 頭指定了一個空值。

我向 WhiteMesa SOAP Server 2.7 發送 清單 1，它作出了一個成功響應，說明 WhiteMesa 可以成功地處理這樣的 SOAPAction 頭。接下來，我向 WhiteMesa 發送 清單 2，它再次成功地對其進行了處理。最后，當我將 SOAPAction 頭的值更改為 "http://differentfromwsdl.org/"（ 清單 3）時，WhiteMesa 未能成功處理該請求并返回一個故障響應。故障字符串為 “Unrecognized 'SOAPAction' HTTP header received.”。WhiteMesa SOAP Server 2.7 還針對 清單 4 中的請求（其中 SOAPAction 值為空）返回一個故障響應。

我還用 IONA XMLBus 和 SOAP::Lite 對清單 1、 3和 4進行了測試，它們成功地處理了 清單 1中的請求，但卻針對清單 3和 4中的請求返回了故障消息。IONA XMLBus 也針對 清單 2（未用雙引號將 URI 引起來）返回了一個故障響應，指出它期望請求中的 SOAPAction 頭要和 WSDL 文件中定義的 SOAPAction 頭一樣，并且要用雙引號括起來。

接下來，我向 Easy SOAP++ 0.6 發送清單 1、 3和 4 中的請求，它返回正確的響應。不管 SOAPAction 頭的值為何，Apache Axis 和 Apache SOAP 2.2 都返回正確的響應。

結論
為了獲得最大程度的互操作性，我推薦用引號將 SOAPAction 頭的值括起來；這個值應該與 WSDL 文件中給定的一致。

2. XML

XML Schema
這一部分描述了各種 SOAP 服務器對編制 SOAP 請求的過程中所使用的不同的 XML Schema 版本表現出的行為。我將對使用測試客戶機測試不同的 SOAP 服務器支持的 XML 模式名稱空間 URI 所得到的測試結果進行分析。

清單 1和 清單 5是完全相同的 SOAP 請求，只是所使用的 XML Schema 版本不同。 清單 1使用 2001 XML Schema URI，而 清單 5使用 1999 URI。我對大量服務器進行了名稱空間 URI 支持測試，然后發現 IONA XMLBus 不能成功處理 1999 URI，但是卻向使用 2001 URI 的 清單 1中的請求返回了一個成功的響應。因此，IONA XMLBus 中的支持被限制為 2001 XML Schema 名稱空間 URI。

我可以有把握地說，2001 URI 將對大多數實現起作用，但是諸如 IBM SOAP Toolkit 和 Apache SOAP 之類較老的實現仍然廣泛存在，這些實現使用的是 1999 URI。Apache SOAP 2.2 既接收 1999 URI，也接收 2001 URI，但是它在響應消息中缺省情況下使用 1999 URI（盡管它確實允許您將其更改為 2001）。因此，您可以預料到那些僅期待 2001 URI 的客戶機（比如 IONA XMLBus）與早期的 SOAP 實現之間將存在互操作性問題。

結論
因為 2001 URI 不久就要成為標準（SOAP 1.2 規范）了，并且它為目前的 SOAP 實現所廣泛支持，所以，對于 XML Schema 名稱空間 URI 來說，最佳做法可能就是在請求中使用 2001 URI 了。

連接類型相關性與 WSDL 知曉性的比較

SOAP 1.1 允許實現提供有關消息中包含的數據的類型信息。這是對數據的文字描述（例如， int 、 string 等）。一些實現依賴該信息來正確地反序列化消息中的數據。Apache SOAP 2.2 是那些在連接時需要顯式輸入信息的實現之一（即，數據類型信息被作為包含數據的元素的一個屬性值提供）；否則它就無法反序列化數據。

我在第 1 部分（ 參考資料）中已經討論了 WSDL 文件的語義。WSDL 文件用于描述 Web 服務。它包含有關 Web 服務所公開的一些方法以及它們的說明的信息。因為 WSDL 文件包含關于哪些參數可以傳遞給一個方法以及期望返回哪些內容的信息，這些信息可以被用于反序列化一個調用方法的 SOAP 請求及其響應。因此，WSDL 文件知曉性是上述問題的解決方案；即，正在反序列化一條 SOAP 消息的運行時應用程序能夠利用 WSDL 文件中提供的數據類型信息。

現在，大多數實現都是 WSDL 知曉的并且不依賴于連接時的類型化。Apache Axis 無需連接時的類型化就可以處理數據，White Mesa 2.7 也可以；但是這里就出現了一個互操作性問題。如果元素名稱和 WSDL 文件中指定的不同，White Mesa 2.7 就不能處理這個請求。對于許多其它實現都是如此。但是另一方面，Apache Axis 能夠處理這樣一個請求而不發出一個故障。所以，如果您為 Apache Axis 編寫一個這樣的請求，它將不會在 White Mesa 2.7 上運行。為服務編寫遵循 WSDL 文件的請求和響應可能是一個更好的做法。這將能處理所有具有 WSDL 知曉性的實現。


3. 數據類型

數據類型兼容性可能是 SOAP 互操作性中最重要的問題。如果兩個應用程序不能理解彼此的數據類型，那么它們就不能執行有意義的數據交換，從而也就不能互操作。

在本系列文章的第二篇文章中已經介紹了數據類型，我在那篇文章中討論了幾種簡單的數據類型和復雜的數據類型。SOAP 使用 XML Schema 數據類型和結構來標識 SOAP 消息中攜帶的數據的類型。

使用 SOAP 進行傳遞的數據首先被序列化；即，數據值被轉換成字符串以在 XML 文檔中傳送。在目的地，這個字符串必須被反序列化，即，被轉換成表示原來的值的數據類型。

將 XML Schema 數據類型映射到適當的本機數據類型是由 SOAP 實現負責的。如果兩個本機數據類型不一致，即，此時 XML 中的同一種數據類型在不同的實現中有不同的值（因此，也就有不同的含義），就可能產生問題。在序列化和反序列化之后保持數據的一致是很重要的。我將詳細討論這個問題。

連接類型相關性與 WSDL 知曉性的比較

SOAP 1.1 允許實現提供有關消息中包含的數據的類型信息。這是對數據的文字描述（例如， int 、 string 等）。一些實現依賴該信息來正確地反序列化消息中的數據。Apache SOAP 2.2 是那些在連接時需要顯式輸入信息的實現之一（即，數據類型信息被作為包含數據的元素的一個屬性值提供）；否則它就無法反序列化數據。

我在第 1 部分（ 參考資料）中已經討論了 WSDL 文件的語義。WSDL 文件用于描述 Web 服務。它包含有關 Web 服務所公開的一些方法以及它們的說明的信息。因為 WSDL 文件包含關于哪些參數可以傳遞給一個方法以及期望返回哪些內容的信息，這些信息可以被用于反序列化一個調用方法的 SOAP 請求及其響應。因此，WSDL 文件知曉性是上述問題的解決方案；即，正在反序列化一條 SOAP 消息的運行時應用程序能夠利用 WSDL 文件中提供的數據類型信息。

現在，大多數實現都是 WSDL 知曉的并且不依賴于連接時的類型化。Apache Axis 無需連接時的類型化就可以處理數據，White Mesa 2.7 也可以；但是這里就出現了一個互操作性問題。如果元素名稱和 WSDL 文件中指定的不同，White Mesa 2.7 就不能處理這個請求。對于許多其它實現都是如此。但是另一方面，Apache Axis 能夠處理這樣一個請求而不發出一個故障。所以，如果您為 Apache Axis 編寫一個這樣的請求，它將不會在 White Mesa 2.7 上運行。為服務編寫遵循 WSDL 文件的請求和響應可能是一個更好的做法。這將能處理所有具有 WSDL 知曉性的實現。

Float（浮點）
與 float 有關的常見問題出現在無窮大的表示上。XML Schema 用字符串 INF表示無窮大。 清單 6在請求中將 INF 作為 float 無窮大發送，Apache SOAP 2.2 服務器以 Infinity返回它，而 Apache Axis 則返回 INF（ 清單 7）。

我還通過發送 清單 6 的 SOAP 請求對 MS SOAP Toolkit 3.0 服務器進行了測試。它返回一個服務器端的故障代碼，且不能將 float 無窮大值 INF反序列化，如同故障字符串 “SoapMapper:Converting data for SoapMapper failed inside the typemapper”所指出的那樣。

另一個問題與 float 精度支持有關。我把 1.23456789E38 作為 float 發送給幾臺 SOAP 服務器（請參閱 清單 8）。IONA XMLBus 返回 1.23456789E38，White Mesa 2.7 服務器返回 1.234568E38，而 MS SOAP ToolKit 3.0 服務器返回 1.23456786051167E+38。盡管這指出了各個實現正在進行互操作的事實，但是這些實現仍然不能將數據重新生成為它的原始值。

Decimal（十進制）
對于 decimal ，XML Schema 規范要求實現要支持的最少位數是 18 位。因為在規范中沒有定義上限，所以各個實現可以隨意設置它們自己的上限。Microsoft ASP.NET Web Services 和 WhiteMesa 2.7 給出的精度最多達 28 位，而 Apache Axis 可以精確支持數百位。這種支持上的差異意味著，當一個 Apache Axis 實現向 WhiteMesa 2.7 實現發送一些大小超過 28 位的 decimal 數字時，額外的精度將被截斷，從而造成數據不一致。

我發送 清單 9 中的 decimal 數字請求（該請求帶有一個很大的 decimal 數字）以了解不同服務器的精度支持。在清單 10、 11和 12中，可以分別看到來自 ASP.NET 服務器、Apache Axis 以及 WhiteMesa 2.7 的響應。4S4C 服務器在對 清單 9的響應中返回的值為 1.235。

DateTime（日期時間）
XML Schema 中用于時間和日期信息的數據類型是 dateTime 。White Mesa 2.7 給出的精度為秒。Apache SOAP 2.2 和 Apache Axis 用 java.util.Date 類表示一個特定的時間實例，精度為毫秒。Microsoft ASP.NET Web Services 使用 Date 類型，該類型可以表示精度為納秒的時間。

現在，如果一個基于 .NET 的 SOAP 客戶機端實現向 SOAP 2.2 實現或 White Mesa 2.7 實現發送 dateTime 信息， dateTime 中額外的精度將被丟失，從而導致數據不一致性。請注意：在 XML Schema 中，精度達到秒是強制性的，而秒的小數部分則是可選的且合法的。

我用 清單 13 中的請求進行了 dateTime 測試。在清單 14、 15、 16和 17中分別顯示了來自 Microsoft ASP.NET Web Services、Apache Axis、WhiteMesa 2.7 和 SOAP::Lite 的響應。

字節數組（Byte Array）
SOAP 允許您以字節數組的形式交換數據。字節數組在被放入一個 XML 文檔中之前，它必須是 base64編碼的。許多實現未能通過 SOAPBuilder（ 參考資料）的第 2 輪（基本）互操作性測試中的 echoBase64 測試。由于本機數據類型格式的差異，一些實現返回的是不一致的值。一些實現通過對已經進行 base64 編碼的值進一步進行 base64 編碼來返回值。

清單 18（使用 1999 XML Schema base64Binary 數據類型）和 清單 19（使用 2001 Schema base64Binary 數據類型）中的請求向 SOAP 服務器發送一個簡單的 echoBase64 方法調用。

Apache SOAP 2.2 在對 清單 18和 清單 19的響應中都返回故障消息。該服務器未能識別兩個例子中的數據類型，因此無法反序列化 base 64 編碼的字節數組。

請看一下 清單 20，它指定 base64 作為數據類型編碼。與 XML Schema 規范定義的 base64Binary 數據類型相比， base64 編碼是由 SOAP 1.1 規范定義的。Apache SOAP 2.2 成功地處理了 清單 20的請求。

IONA XMLBus 成功地處理了 19，但處理 18（請回顧一下講述 XML Schema 問題的部分，在那部分中，我發現了 IONA XMLBus 只支持 2001 XML Schema URI）時失敗了。它也無法識別 清單 20 中的請求中的 SOAP-ENC:base64 數據類型實例，然后返回一個故障字符串。

從上面的測試中能明顯看出，當 Apache SOAP 2.2 和 IONAXMLBus 交換 base64 編碼的字節數組時，它們之間有互操作性問題。

數組（Array）
數組形式的數據對實現來說一直是一個困難的測試，尤其是當情形復雜，滿是使用嵌套的數組、多維數組以及嵌套結構（struct）的情況時。

struct 是一種復雜的、用戶定義的數據類型，它可以包含簡單的或更復雜的數據類型。具有 C 語言編程經驗的讀者可能會想在 C struct 和 XML Schema struct 之間做一個類比。

有無數種方法可以把一維數組和多維數組與其它的數據類型結合在 structs 中。因此，我設計了大量 SOAP 請求來測試不同 SOAP 服務器的行為。這些測試遵循 SOAPBuilders 的第 2 輪（B 組）測試套件。您可以在 SOAPBuilders 的第 2 輪 Web 站點上得到 B 組測試的 WSDL 文件。

清單 21 包含了一個簡單的 strings 數組。
清單 22 包含了一個 structs 數組。該 struct 包含了一個 string 、一個 float 和一個 int 數據類型。
清單 23 包含一個二維的 strings 數組。
清單 24為二維數組定義了一個偏移量（這個值定義了應該從哪個位置開始處理數組）。
清單 25 包含了一個 struct ，該 struct 帶有一個嵌套的 strings 數組。
清單 26包含一個二維數組，未指定最里面一維的大小。
我所測試的所有 SOAP 實現對于簡單類型和復雜類型的數組（即 清單 21和 清單 22）都沒有問題。

用清單 21、 22、 23、 24、 25和 26對 WhiteMesa 2.7 服務器進行了測試。盡管 只是當指定了偏移量（大于零）時，WhiteMesa 2.7 服務器未能成功處理 清單 25，但它還是成功地處理了所有請求。White Mesa 2.7 就已經顯示了在最里面一維的大小未被指定（ 清單 26）時能夠處理二維數組。

我向 SOAP::Lite 發送 清單 23中的請求，SOAP::Lite 無法處理該請求，它返回一個帶有故障字符串 “Not implemented, because SOAP::Lite does not generate multidimensional arrays (yet accepts ;))”的故障響應。 清單 26中的請求能被 WhiteMesa 成功地處理，卻不能被許多其它的實現成功處理；SOAP::Lite 和 Apache Axis 返回故障消息。

結論
包括數組以及數組的不同組合的交換的數據交換，對于大多數 SOAP 實現可能是可以的，除了上面我已經指出的幾個實現外。為了確保最大程度的互操作性和數據一致性，Web 服務開發者應該編寫全面的數據測試，這些測試由期望的數據模式的所有可能變體組成，因為那樣做可以找出可以解決的問題并確認應用程序和數據一致性。

雜項

在 SOAP 中，還有其它可能引發互操作性問題的地方。這些問題可能會因引擎無法處理 mustUnderstand SOAP 頭而顯露出來。可以通過定制頭來擴展 SOAP 功能。這個可擴展性還為最終可能會導致互操作性問題的專有的、非標準的解決方案打開了解決渠道。SOAP 允許使用一些實現（例如，Apache SOAP 2.2）所不支持的多個返回參數。編碼模式描述了將數據序列化到 XML 以及將數據從 XML 反序列化時所遵循的規則。遺憾的是，盡管 SOAP 1.1 確實提議了一個 SOAP 消息的編碼，但是它并沒有為 SOAP 消息指定一個缺省編碼。SOAP 實現者并沒有被該規范所束縛，不會為了遵循規范而實現規范定義的編碼。缺少缺省編碼模式可能會導致互操作性問題。


結束語

對于那些正在計劃在現在的 SOAP 實現上構建 Web 服務的開發者，或者那些正在編寫他們自己的 SOAP 服務器和客戶機的開發者，現在我可以提供幾點建議。

如果您正在計劃使用 SOAP 1.1 實現，請在您的請求中用引號把 SOAPAction 頭括起來，并且要確保它與服務的 WSDL 文件中的 SOAPAction 頭一致。
請采用 XML Schema 的 2001 名稱空間 URI，因為它現在是事實上的標準。
請遵照 SOAP 1.1 定義的編碼，并請確保您發送和接收的數據確實是以它應該的格式進行的。
您的方法元素名稱應該遵循 WSDL 描述。
請在 SOAP 消息中提供連接時的數據類型信息。


清單 1. SOAPAction 值為 "http://soapinterop.org/" 的 SOAP 請求。
?


清單 2. SOAPAction 值（未加引號的）為 http://soapinterop.org/ 的 SOAP 請求。



清單 3. SOAPAction 值為 "http://differentfromwsdl.org/" 的 SOAP 請求。



清單 4. SOAPAction 值為空的 SOAP 請求。



清單 5. 帶有 XML Schema 的 1999 名稱空間 URI 的 SOAP 請求。


清單 6. “INF”作為 float 無窮大的 SOAP 請求。



清單 7. Apache Axis 服務器對清單 6 中的請求的響應。


清單 8. 用于對 SOAP 服務器進行 float 值測試的 SOAP 請求。



清單 9. 很大的十進制數的 SOAP 請求。



清單 10. 來自 Microsoft 的 ASP.NET Web Services 對清單 9 中的請求的 SOAP 響應。



清單 11. 來自 Apache Axis 的對清單 9 中的請求的 SOAP 響應。

0


清單 12. 來自 WhiteMesa 2.7 的對清單 9 中的請求的 SOAP 響應。



清單 13. SOAP dataTime 數據類型請求。



清單 14. 來自 Microsoft ASP.NET Web Services 的對清單 13 中的請求的響應。



清單 15. 來自 Apache Axis 的對清單 13 中的請求的響應。

0

清單 16. 來自 WhiteMesa 2.7 的對清單 13 中的請求的響應。


清單 17. 來自 SOAP::Lite 的對清單 13 中的請求的響應。



清單 18. 帶有 1999 XML Schema URI 限定的 base64Binary 數據類型的 SOAP 請求。



清單 19. 帶有 2001 XML Schema URI 限定的 base64Binary 數據類型的 SOAP 請求。


清單 20. 帶有 SOAP-ENC 限定的 base64 數據類型的 SOAP 請求。



清單 21. SOAP 請求中的一個字符串數組。



清單 22. SOAP 請求中的結構數組。


清單 23. SOAP 請求中的一個二維字符串數組。


清單 24. SOAP 請求中一個帶有偏移量的二維字符串數組。



清單 25. 結構中帶有一個嵌套的字符串數組的 SOAP 請求。



清單 26. 帶有二維數組的 SOAP 請求，未指定行（最里面一維）大小。