理解Web服務(wù)互操作性

申請免費試用、咨詢電話：400-8352-114

理解Web服務(wù)互操作性 
 
－－集成多供應(yīng)商Web服務(wù)實現(xiàn)的問題

Frank Cohen （fcohen@pushtotest.com）

總裁，PushToTest

2002 年 2 月

Web 服務(wù)技術(shù)許諾使軟件應(yīng)用程序之間的互操作性達到新的級別。那么，平臺供應(yīng)商、軟件開發(fā)者及實用程序供應(yīng)商爭先恐后的給他們的軟件加上 SOAP、WSDL 和 UDDI 功能也就不足為奇了。在這篇文章里，F(xiàn)rank Cohen 描述了 Web 服務(wù)實現(xiàn)的不一致性以及如何評估 SOAP 技術(shù)以更快的交付更好的軟件。

噢，美麗的新世界

一踏上這個新的 Web 服務(wù)之島，人們也許會想：“噢，美麗的新世界擁有這樣的奇跡！”于是，Web 服務(wù)的實現(xiàn)就在眼前。許多平臺供應(yīng)商、獨立軟件供應(yīng)商以及實用程序軟件開發(fā)者們都已經(jīng)在各自的產(chǎn)品中實現(xiàn)了 Web 服務(wù)協(xié)議（SOAP、WSDL 和 UDDI）。盡管這些協(xié)議現(xiàn)在已經(jīng)將近兩年了，下一個規(guī)范（例如 SOAP 1.2）的工作草案也在起草當(dāng)中，但是開發(fā)者們必須就規(guī)范的某些部分解釋其含義。解釋使互操作性問題滲透到了基于 SOAP 的 Web 服務(wù)中。

Web 服務(wù)互操作性的目的是提供從一個軟件應(yīng)用程序到另外一個軟件應(yīng)用程序無縫的、自動的連接。SOAP、WSDL 和 UDDI 協(xié)議定義了一種自描述的方式發(fā)現(xiàn)并調(diào)用軟件應(yīng)用程序中的方法 － 不必考慮位置或平臺。數(shù)據(jù)被編入 XML 請求和響應(yīng)文檔，并使用 HTTP 或基于消息的協(xié)議在軟件包之間移動數(shù)據(jù)?；ゲ僮餍詥栴}就潛伏在發(fā)現(xiàn)、定義以及請求／響應(yīng)機制中。

發(fā)現(xiàn)

在 Web 服務(wù)烏托邦的夢想世界里，每個軟件應(yīng)用程序都以自發(fā)現(xiàn)和自分類方法被編碼。缺少需要的功能的軟件查詢基于 UDDI 的服務(wù)注冊中心，并自動同找到的 Web 服務(wù)達成協(xié)議處理這一任務(wù)。一找到 Web 服務(wù)功能，WSDL 和 SOAP 就可以通信了。然后的問題就是將該功能所做的事分類，以使其可以被發(fā)現(xiàn)。UDDI 定義了 TModel，它就是描述功能的位置、路徑和特性的分類法。

UDDI 使企業(yè)可以托管可用 Web 服務(wù)的在線注冊中心。Microsoft、HP 和 IBM 已經(jīng)開始在公共的因特網(wǎng)上向企業(yè)提供 UDDI 注冊中心。企業(yè)使用 UDDI TModel 系統(tǒng)將被托管的 Web 服務(wù)分類。而問題正在于此：UDDI 允許有多種分類法并期望自己管理注冊中心里的錯誤條目。例如，假設(shè)有一個打印并發(fā)送發(fā)票的 Web 服務(wù)用 SIC 代碼把自己列入一個 UDDI 注冊中心，但沒有列出地理信息。在地球的另一端使用這樣的 Web 服務(wù)是可行的。但是，自己去寄信可能更簡便。

最終 UDDI 將會被傳統(tǒng)分類法的提供者們很好的采用及理解，這些分類法包括 LCSH（美國國會圖書館主題標(biāo)引，Library of Congress Subject Heading）、FAST (Faceted LCSH)、DDC（杜威十進分類法，Dewey Decimal Classification）以及 LCC（美國國會圖書館圖書分類法，Library of Congress Classification）。到分類法專家增長了他們開發(fā)和維護 UDDI 目錄結(jié)構(gòu)的實踐知識為止，請為互操作性問題作一些規(guī)劃。

定義

Web 服務(wù)用 WSDL 來定義如何請求基于 SOAP 的方法。WSDL 假設(shè)多個公司合作定義定制數(shù)據(jù)類型。由協(xié)作組織測試這樣的合作，這些協(xié)作組織正在建立互操作性測試套件。例如，SOAPBuilder 是 SOAP 開發(fā)者的一個開放組織，這個組織定義互操作性測試套件來檢查 SOAP 定制數(shù)據(jù)類型的兼容性。現(xiàn)今出現(xiàn)的測試套件從 SOAP 接口的 WSDL 定義開始。他們測試請求和響應(yīng)文檔的內(nèi)容的有效數(shù)據(jù)。

這是繼 WSDL 成果之后的補充的能量。諸如 Cape Clear CapeStudio 和 BEA Cajun 的新技術(shù)自動為基于 SOAP 的 Web 服務(wù)開發(fā) WSDL 文檔。諸如此類的工具消除了在開發(fā)者手工編寫 WSDL 文檔時出現(xiàn)的構(gòu)造拙劣的 WSDL。

清單 1：自動生成的 WSDL 文檔

<?xml version="1.0" ?>
<definitions name="PushToTestService"
targetNamespace="http://www.pushtotest.com/pushtotestservice.wsdl">
<message name="testRequest">
  <part name="userName" type="xsd:string" />
  <part name="authenticationToken" type="xsd:string" />
  <part name="goodUnitl" type="xsd:Date" />
  </message>
. . .

人們認(rèn)為是 WSDL 文檔導(dǎo)致了互操作性問題。例如，考慮一下上面的軟件測試 Web 服務(wù)的 WSDL 文檔片斷。WSDL 定義了如何發(fā)送 testRequest 命令。但 <definitions> 元素沒有定義名稱空間。正確的 <definitions> 元素應(yīng)當(dāng)看起來如清單 2 所示的樣子。

清單 2：<definition> 元素的正確使用

<definitions xmlns:s="http://www.w3.org/2001/XMLSchema"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s0="http://tempuri.org/"
targetNamespace="http://tempuri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/">

開發(fā)者可能會認(rèn)為 Web 服務(wù)默認(rèn)使用標(biāo)準(zhǔn) W3C SOAP 名稱空間。盡管這對基本數(shù)據(jù)類型（如 String）可能是可行的，對于將會在本文后面的內(nèi)容中出現(xiàn)的 Date 數(shù)據(jù)類型會有已知的互操作性問題。不指定名稱空間，Web 服務(wù)就可能無法正確的處理數(shù)據(jù)類型。

請求／響應(yīng)

SOAP 定義了軟件應(yīng)用程序相互調(diào)用方法和傳遞數(shù)據(jù)的標(biāo)準(zhǔn)方式。SOAP 請求是 XML 文檔，這些文檔含有對名稱空間、被調(diào)用方法以及數(shù)據(jù)的描述。XML 試圖使開發(fā)者們可以相當(dāng)靈活的編寫 XML 元素和定義。這樣的靈活性對 SOAP 互操作性而言是一個問題。

例如，一個典型的 SOAP 響應(yīng)文檔看起來可能會如清單 3 這樣。

清單 3：一個典型的 SOAP 響應(yīng)

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:echoStringResponse xmlns:ns1="http://soapinterop.org/">
<result xsi:type="xsd:string">Hello!</result>
</ns1:echoStringResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

這個響應(yīng)文檔正在發(fā)回一個包含文本“Hello！”的 String。<result> 元素還包括 xsi:type="xsd:string" 參數(shù)，這個參數(shù)被反序列化成一個 Java 的 String 對象。許多 SOAP 工具在請求和響應(yīng)文檔中加入了顯式類型定義信息。另一方面，一些 SOAP 庫返回?zé)o類型信息的響應(yīng)。

清單 4：無類型信息的另一個 SOAP 響應(yīng)

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:echoStringResponse xmlns:ns1="http://soapinterop.org/">
<result>Hello, I'm a string!</result>
</ns1:echoStringResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

上面的響應(yīng)文檔中的 <result> 元素沒有包含類型信息。這樣，反序列化 <result> 值的 SOAP 庫必須查看服務(wù)的 WSDL 描述來找出返回類型的描述。如果 WSDL 沒有定義響應(yīng)類型，那么返回的將是哪種類型的對象就沒有確定答案了。

數(shù)據(jù)類型

數(shù)據(jù)類型在 Web 服務(wù)中就如同輪胎與路面的關(guān)系 －“一拍即合”。SOAP 使用序列化器和反序列化器對象把軟件應(yīng)用程序的本機語言翻譯成通過網(wǎng)絡(luò)傳輸請求的 SOAP 協(xié)議。在此，本機語言引入了對數(shù)據(jù)的依賴。例如，Java 定義日期對象的方式同 Microsoft .NET C++ 定義日期對象的方式并不相同。這將帶來允許同名的 SOAP 數(shù)據(jù)類型具有不同的實現(xiàn)的不良后果?；ゲ僮餍詥栴}來了。

不能通過互操作性測試的最常見的數(shù)據(jù)類型是浮點數(shù)和日期。

浮點數(shù)和十進制數(shù)據(jù)類型

浮點數(shù)在 SOAP 中被表示成十進制數(shù)字字符串。浮點數(shù)的 SOAP 定義還使工程師長時間使用的標(biāo)記法來表示指數(shù)成為可能。一般情況下，這種方法會如您所愿。但是，浮點數(shù)在被推入時會遇到問題。

例如，最初的 IBM SOAP4J 實現(xiàn)（現(xiàn)在是 Apache SOAP 和 Apache AXIS 庫）使用 Java 的 toString 方法以及構(gòu)造函數(shù)把 SOAP 文檔中找到的浮點值轉(zhuǎn)換成 Java 對象。數(shù)字作為一串十進制數(shù)字出現(xiàn)。當(dāng)涉及序列化浮點數(shù)“無窮大（infinity）”時，Java 輸出“Infinity”這個字符串。另一方面，XML Schema 把無窮大序列化為“INF”。這導(dǎo)致了 SOAP4J 和其它 SOAP 工具箱之間的互操作性問題。

正如因特網(wǎng)產(chǎn)生于網(wǎng)絡(luò)管理員們的合作一樣，現(xiàn)在我們看到 SOAP 的實現(xiàn)者們正同心協(xié)力解決互操作性問題。前身是 SOAP4J 的 Apache SOAP 被改為接受“INF”作為序列化無窮大的一種有效方式。

十進制數(shù)據(jù)類型在被推入時也會受到語言依賴的影響。十進制數(shù)據(jù)類型可以表示達 40 位精度的大數(shù)。除非服務(wù)器端和客戶機端是在相同的語言上實現(xiàn)的，否則依賴 SOAP 請求或響應(yīng)中的所有 40 位會有問題。對于日期的秒的小數(shù)部分和小數(shù)位上的尾零也是如此。

語言依賴性引入的互操作性隱患的一個很好的示例就是 BigDecimal。十進制數(shù)字是銀行應(yīng)用程序的金融計算的一個必要部分，銀行應(yīng)用程序里會需要很大的數(shù)字。十進制數(shù)據(jù)類型的 XML Schema 規(guī)范允許任意精度。十進制數(shù)據(jù)類型可以表示 1000 位精度，也就是說，一個被表示成 1000 個一位數(shù)字的字符串的十進制數(shù)。Apache SOAP 是基于 BigDecimal 數(shù)據(jù)類型的 Java 實現(xiàn)。根據(jù)底層操作系統(tǒng)（Solaris、Windows 等），Java 的 BigDecimal 有一個數(shù)字精度的上限。

XML Schema 對這些類別的互操作性問題的解決辦法是定義最低限度滿足要求的實現(xiàn)規(guī)范。就十進制數(shù)據(jù)類型而言，XML Schema 要求至少要有 18 位精度。Apache 和 Java 滿足這一要求。但是，這并不意味著基于 SOAP 的 Web 服務(wù)會接受這樣的最低精度。

Microsoft .NET 實現(xiàn)處理 BigDecimal 數(shù)據(jù)類型達 29 位精度。那么帶 BigDecimal 數(shù)據(jù)類型的 Apache SOAP 請求接收到一個 .NET 響應(yīng)時，多出來的那些位精度會怎么樣呢？不幸的是，答案要取決于本機 SOAP 序列化器和反序列化器實現(xiàn)。而且問題在于，SOAP 事務(wù)是有效的但數(shù)據(jù)是錯誤的。開發(fā)者們必須精于把數(shù)據(jù)測試和保護編進他們的軟件應(yīng)用程序中才能照顧到 SOAP 交換帶來的無效數(shù)據(jù)。

Date 數(shù)據(jù)類型

互操作性問題對日期數(shù)據(jù)類型的影響程度要甚于浮點小數(shù)數(shù)據(jù)類型。XML Schema 定義 dateTime 數(shù)據(jù)類型包含世紀(jì)、年、月、日、小時、分鐘和秒。但是，毫秒、微秒甚至更小的時間度量單位呢？我們生活在一個 1.1 GHz Intel CPU 賣不到 $150 的世界里，用戶要求 Web 服務(wù)執(zhí)行最多只要 2-3 秒鐘。在幾乎所有的 Web 服務(wù)性能的度量標(biāo)準(zhǔn)中，毫秒都要計算在內(nèi)。

XML Schema 規(guī)定秒之后的任意個數(shù)位可以被編碼成 dateTime 數(shù)據(jù)類型，但是并沒有規(guī)定應(yīng)用程序必須支持的數(shù)位的最小數(shù)目。Apache SOAP 使用 Java Date 類（java.util.Date）來序列化和反序列化 dateTime 數(shù)據(jù)類型。Java Date 支持幾乎接近毫秒的精度。.NET 的 Date 數(shù)據(jù)類型使用達 4 位精度的亞秒值，所以納秒可以用 .NET Date 數(shù)據(jù)類型來表示。

前景

現(xiàn)在的 Web 服務(wù)是由核心 UDDI、WSDL 和 SOAP 協(xié)議提供的。定義工作流自動化、Web 服務(wù)管理服務(wù)以及垂直營銷協(xié)議的另一層協(xié)議即將出現(xiàn)。Web 服務(wù)對開發(fā)者們構(gòu)建高度集成的解決方案很有幫助。因此，在工作流自動化 Web 服務(wù)同垂直營銷 Web 服務(wù)結(jié)合時看到互操作性問題的到來并非意料之外的事。

如果 Web 服務(wù)工具箱得到持續(xù)的改進以解決互操作性問題，那么顧客、用戶和企業(yè)將比使用現(xiàn)有的標(biāo)準(zhǔn)（CORBA、DCOM 和 RMI）更高效的解決系統(tǒng)集成問題。比較認(rèn)真的 Web 服務(wù)工具箱供應(yīng)商一直在努力解決互操作性問題。如果互操作性問題被擱淺或者加劇，那么要實現(xiàn)集成系統(tǒng)，我們就不可避免的要花費更多的專業(yè)服務(wù)且更遲的考慮采納 Web 服務(wù)。

同時，Web 服務(wù)即將以幾乎普遍的采用作為很好的開端。真正的互操作性難題可能會是在 SOAP 和非 SOAP 方法需要通信的領(lǐng)域，如 IIOP 上的 CORBA。

參考資料

• 要參加這篇文章的討論論壇，請單擊文章上部或下部的討論。
  
• 交互性測試套件檢查 SOAP 實現(xiàn)。
  
• Load，用來測試基于 SOAP 的 Web 服務(wù)的功能、可擴展性及性能的開放源碼的免費實用程序。
  
• Web Services Definition Language（WSDL）規(guī)范。
  
• SOAP 協(xié)議規(guī)范。
  
• Microsoft 的 SOAP 資源。

關(guān)于作者

Frank Cohen 是一個軟件企業(yè)家，自 1975 以來他一直在促進個人計算機在世界范圍的成功。開始，他編寫微型計算機的操作系統(tǒng)，協(xié)助視頻游戲成為一個行業(yè)，幫助確立 Norton 實用程序經(jīng)銷權(quán)，把 Apple 的成就引入中間件和因特網(wǎng)技術(shù)，并且在最近擔(dān)任 Sun Community Server、Inclusion.net 以及 TuneUp.com 的首席設(shè)計師。Frank 維護 Load 并經(jīng)營著 PushToTest（這是一個可擴展性和性能測試解決方案公司）。www.PushToTest.com 網(wǎng)站上有更多可用信息。您可以通過 fcohen@pushtotest.com 與 Frank 聯(lián)絡(luò)。