一踏上這個新的 Web 服務之島，人們也許會想：“噢，美麗的新世界擁有這樣的奇蹟！”於是，Web 服務的實現就在眼前。許多平臺供應商、獨立軟件供應商以及實用程序軟件開發者們都已經在各自的產品中實現了 Web 服務協議（SOAP、WSDL 和 UDDI）。儘管這些協議現在已經將近兩年了，下一個規範（例如 SOAP 1.2）的工作草案也在起草當中，但是開發者們必須就規範的某些部分解釋其含義。解釋使互操作性問題滲透到了基於 SOAP 的 Web 服務中。
Web 服務互操作性的目的是提供從一個軟件應用程序到另外一個軟件應用程序無縫的、自動的連接。SOAP、WSDL 和 UDDI 協議定義了一種自描述的方式發現並調用軟件應用程序中的方法 － 不必考慮位置或平臺。數據被編入 XML 請求和響應文檔，並使用 HTTP 或基於消息的協議在軟件包之間移動數據。互操作性問題就潛伏在發現、定義以及請求／響應機制中。
  |
|
在 Web 服務烏托邦的夢想世界裏，每個軟件應用程序都以自發現和自分類方法被編碼。缺少需要的功能的軟件查詢基於 UDDI 的服務註冊中心，並自動同找到的 Web 服務達成協議處理這一任務。一找到 Web 服務功能，WSDL 和 SOAP 就可以通信了。然後的問題就是將該功能所做的事分類，以使其可以被發現。UDDI 定義了 TModel，它就是描述功能的位置、路徑和特性的分類法。
UDDI 使企業可以託管可用 Web 服務的在線註冊中心。Microsoft、HP 和 IBM 已經開始在公共的因特網上向企業提供 UDDI 註冊中心。企業使用 UDDI TModel 系統將被託管的 Web 服務分類。而問題正在於此：UDDI 允許有多種分類法並期望自己管理註冊中心裏的錯誤條目。例如，假設有一個打印併發送發票的 Web 服務用 SIC 代碼把自己列入一個 UDDI 註冊中心，但沒有列出地理信息。在地球的另一端使用這樣的 Web 服務是可行的。但是，自己去寄信可能更簡便。
最終 UDDI 將會被傳統分類法的提供者們很好的採用及理解，這些分類法包括 LCSH（美國國會圖書館主題標引，Library of Congress Subject Heading）、FAST (Faceted LCSH)、DDC（杜威十進分類法，Dewey Decimal Classification）以及 LCC（美國國會圖書館圖書分類法，Library of Congress Classification）。到分類法專家增長了他們開發和維護 UDDI 目錄結構的實踐知識爲止，請爲互操作性問題作一些規劃。
|
|
Web 服務用 WSDL 來定義如何請求基於 SOAP 的方法。WSDL 假設多個公司合作定義定製數據類型。由協作組織測試這樣的合作，這些協作組織正在建立互操作性測試套件。例如，SOAPBuilder 是 SOAP 開發者的一個開放組織，這個組織定義互操作性測試套件來檢查 SOAP 定製數據類型的兼容性。現今出現的測試套件從 SOAP 接口的 WSDL 定義開始。他們測試請求和響應文檔的內容的有效數據。
這是繼 WSDL 成果之後的補充的能量。諸如 Cape Clear CapeStudio 和 BEA Cajun 的新技術自動爲基於 SOAP 的 Web 服務開發 WSDL 文檔。諸如此類的工具消除了在開發者手工編寫 WSDL 文檔時出現的構造拙劣的 WSDL。
清單 1：自動生成的 WSDL 文檔
|
人們認爲是 WSDL 文檔導致了互操作性問題。例如，考慮一下上面的軟件測試 Web 服務的 WSDL 文檔片斷。WSDL 定義瞭如何發送 testRequest 命令。但 <definitions> 元素沒有定義名稱空間。正確的 <definitions> 元素應當看起來如 清單 2所示的樣子。
清單 2：<definition> 元素的正確使用
|
開發者可能會認爲 Web 服務默認使用標準 W3C SOAP 名稱空間。儘管這對基本數據類型（如 String）可能是可行的，對於將會在本文後面的內容中出現的 Date 數據類型會有已知的互操作性問題。不指定名稱空間，Web 服務就可能無法正確的處理數據類型。
|
|
SOAP 定義了軟件應用程序相互調用方法和傳遞數據的標準方式。SOAP 請求是 XML 文檔，這些文檔含有對名稱空間、被調用方法以及數據的描述。XML 試圖使開發者們可以相當靈活的編寫 XML 元素和定義。這樣的靈活性對 SOAP 互操作性而言是一個問題。
例如，一個典型的 SOAP 響應文檔看起來可能會如 清單 3這樣。
清單 3：一個典型的 SOAP 響應
|
這個響應文檔正在發回一個包含文本“Hello！”的 String。 <result> 元素還包括 xsi:type="xsd:string" 參數，這個參數被反序列化成一個 Java 的 String 對象。許多 SOAP 工具在請求和響應文檔中加入了顯式類型定義信息。另一方面，一些 SOAP 庫返回無類型信息的響應。
清單 4：無類型信息的另一個 SOAP 響應
|
上面的響應文檔中的 <result> 元素沒有包含類型信息。這樣，反序列化 <result> 值的 SOAP 庫必須查看服務的 WSDL 描述來找出返回類型的描述。如果 WSDL 沒有定義響應類型，那麼返回的將是哪種類型的對象就沒有確定答案了。
|
|
數據類型在 Web 服務中就如同輪胎與路面的關係 －“一拍即合”。SOAP 使用序列化器和反序列化器對象把軟件應用程序的本機語言翻譯成通過網絡傳輸請求的 SOAP 協議。在此，本機語言引入了對數據的依賴。例如，Java 定義日期對象的方式同 Microsoft .NET C++ 定義日期對象的方式並不相同。這將帶來允許同名的 SOAP 數據類型具有不同的實現的不良後果。互操作性問題來了。
不能通過互操作性測試的最常見的數據類型是浮點數和日期。
浮點數在 SOAP 中被表示成十進制數字字符串。浮點數的 SOAP 定義還使工程師長時間使用的標記法來表示指數成爲可能。一般情況下，這種方法會如您所願。但是，浮點數在被推入時會遇到問題。
例如，最初的 IBM SOAP4J 實現（現在是 Apache SOAP 和 Apache AXIS 庫）使用 Java 的 toString 方法以及構造函數把 SOAP 文檔中找到的浮點值轉換成 Java 對象。數字作爲一串十進制數字出現。當涉及序列化浮點數“無窮大（infinity）”時，Java 輸出“Infinity”這個字符串。另一方面，XML Schema 把無窮大序列化爲“INF”。這導致了 SOAP4J 和其它 SOAP 工具箱之間的互操作性問題。
正如因特網產生於網絡管理員們的合作一樣，現在我們看到 SOAP 的實現者們正同心協力解決互操作性問題。前身是 SOAP4J 的 Apache SOAP 被改爲接受“INF”作爲序列化無窮大的一種有效方式。
十進制數據類型在被推入時也會受到語言依賴的影響。十進制數據類型可以表示達 40 位精度的大數。除非服務器端和客戶機端是在相同的語言上實現的，否則依賴 SOAP 請求或響應中的所有 40 位會有問題。對於日期的秒的小數部分和小數位上的尾零也是如此。
語言依賴性引入的互操作性隱患的一個很好的示例就是 BigDecimal。十進制數字是銀行應用程序的金融計算的一個必要部分，銀行應用程序裏會需要很大的數字。十進制數據類型的 XML Schema 規範允許任意精度。十進制數據類型可以表示 1000 位精度，也就是說，一個被表示成 1000 個一位數字的字符串的十進制數。Apache SOAP 是基於 BigDecimal 數據類型的 Java 實現。根據底層操作系統（Solaris、Windows 等），Java 的 BigDecimal 有一個數字精度的上限。
XML Schema 對這些類別的互操作性問題的解決辦法是定義最低限度滿足要求的實現規範。就十進制數據類型而言，XML Schema 要求至少要有 18 位精度。Apache 和 Java 滿足這一要求。但是，這並不意味着基於 SOAP 的 Web 服務會接受這樣的最低精度。
Microsoft .NET 實現處理 BigDecimal 數據類型達 29 位精度。那麼帶 BigDecimal 數據類型的 Apache SOAP 請求接收到一個 .NET 響應時，多出來的那些位精度會怎麼樣呢？不幸的是，答案要取決於本機 SOAP 序列化器和反序列化器實現。而且問題在於，SOAP 事務是有效的但數據是錯誤的。開發者們必須精於把數據測試和保護編進他們的軟件應用程序中才能照顧到 SOAP 交換帶來的無效數據。
互操作性問題對日期數據類型的影響程度要甚於浮點小數數據類型。XML Schema 定義 dateTime 數據類型包含世紀、年、月、日、小時、分鐘和秒。但是，毫秒、微秒甚至更小的時間度量單位呢？我們生活在一個 1.1 GHz Intel CPU 賣不到 $150 的世界裏，用戶要求 Web 服務執行最多隻要 2-3 秒鐘。在幾乎所有的 Web 服務性能的度量標準中，毫秒都要計算在內。
XML Schema 規定秒之後的任意個數位可以被編碼成 dateTime 數據類型，但是並沒有規定應用程序必須支持的數位的最小數目。Apache SOAP 使用 Java Date 類（java.util.Date）來序列化和反序列化 dateTime 數據類型。Java Date 支持幾乎接近毫秒的精度。.NET 的 Date 數據類型使用達 4 位精度的亞秒值，所以納秒可以用 .NET Date 數據類型來表示。
|
|
現在的 Web 服務是由核心 UDDI、WSDL 和 SOAP 協議提供的。定義工作流自動化、Web 服務管理服務以及垂直營銷協議的另一層協議即將出現。Web 服務對開發者們構建高度集成的解決方案很有幫助。因此，在工作流自動化 Web 服務同垂直營銷 Web 服務結合時看到互操作性問題的到來並非意料之外的事。
如果 Web 服務工具箱得到持續的改進以解決互操作性問題，那麼顧客、用戶和企業將比使用現有的標準（CORBA、DCOM 和 RMI）更高效的解決系統集成問題。比較認真的 Web 服務工具箱供應商一直在努力解決互操作性問題。如果互操作性問題被擱淺或者加劇，那麼要實現集成系統，我們就不可避免的要花費更多的專業服務且更遲的考慮採納 Web 服務。
同時，Web 服務即將以幾乎普遍的採用作爲很好的開端。真正的互操作性難題可能會是在 SOAP 和非 SOAP 方法需要通信的領域，如 IIOP 上的 CORBA。
|
|
